Biological Database Lecture 2 PDF
Document Details
Uploaded by JollyTsilaisite8948
Delta University Egypt
Amira El_Zeiny
Tags
Summary
This document presents a lecture on relational databases, covering topics such as relations, tuples, attributes, properties of relations, relational keys (super keys, candidate keys, primary keys, foreign keys), representing relational database schemas, integrity constraints, views, conceptual database design, and a sample database application. It's appropriate for an introductory to intermediate-level undergraduate database course.
Full Transcript
Lecture 2 : The Relational Model Amira El_Zeiny Structure of Relational Databases relation, tuple, and attribute not table, row, and column A relational database : a collection of normalized relations with distinct relation names. Properties of Relations The relation has a name...
Lecture 2 : The Relational Model Amira El_Zeiny Structure of Relational Databases relation, tuple, and attribute not table, row, and column A relational database : a collection of normalized relations with distinct relation names. Properties of Relations The relation has a name that is distinct from all other relation names in the relational schema; each cell of the relation contains exactly one atomic (single) value; each attribute has a distinct name; the values of an attribute are all from the same domain; each tuple is distinct; there are no duplicate tuples; the order of attributes has no significance; the order of tuples has no significance, theoretically. Degree The degree of a relation is the number of attributes it contains. Cardinality The cardinality of a relation is the number of tuples it contains Relational Keys Super key An attribute, or set of attributes, that uniquely identifies a tuple within a relation. It may contain additional attributes that are not necessary for unique identification, Candidate key A super key such that no proper subset is a super key within the relation. uniqueness – in each tuple of R, the values of K uniquely identify that tuple; irreducibility – no proper subset of K has the uniqueness property. composite key: when a key consists of more than one attribute Primary key The candidate key that is selected to identify tuples uniquely within the relation. Foreign key An attribute, or set of attributes, within one relation that matches the candidate key of some other (possibly the same) relation. Representing Relational Database Schemas Branch (branchNo, street, city, postcode) Integrity Constraints Null : Represents a value for an attribute that is currently unknown or is not applicable for this tuple. Entity Integrity: In a base relation, no attribute of a primary key can be null. Referential Integrity: If a foreign key exists in a relation, either the foreign key value must match a candidate key value of some tuple in its home relation or the foreign key value must be wholly null. General constraints : Additional rules specified by the users or database administrators of a database that define or constrain some aspect of the enterprise. Views Base relation :A named relation corresponding to an entity in the conceptual schema, whose tuples are physically stored in the database. View The dynamic result of one or more relational operations operating on the base relations to produce another relation. A view is a virtual relation that does not necessarily exist in the database but can be produced upon request by a particular user, at the time of request Database development lifecycle Conceptual database design In the conceptual design step, we create a conceptual schema for the database, using a high-level conceptual data model. The conceptual schema is a concise description of the data requirements of the users and includes detailed descriptions of the entity types, relationships, and constraints; these are expressed using the concepts provided by the high-level data model. The high-level conceptual schema can also be used as a reference to ensure that all users’ data requirements are met and that the requirements do not conflict. ER model concepts are used for conceptual schema design A Sample Database Application The company is organized into departments. Each department has a unique name, a unique number, and a particular employee who manages the department. We keep track of the start date when that employee began managing the department. A department may have several locations. A department controls a number of projects, each of which has a unique name, a unique number, and a single location. We store each employee’s name, Social Security number,2 address, salary, sex (gender), and birth date. An employee is assigned to one department, but may work on several projects, which are not necessarily controlled by the same department. We keep track of the current number of hours per week that an employee works on each project. We also keep track of the direct supervisor of each employee (who is another employee). We want to keep track of the dependents of each employee for insurance purposes. We keep each dependent’s first name, sex, birth date, and relationship to the employee.