Database Design

Advantages

• Work in all modern databases.
• Easy to integrate different systems.
• Easy to migrate from one vendor database to another.
• Less maintenance cost.

• Relatively complex syntax compared to vendor SQLs.
• Higher development cost.

Generally, ERD's look like this:

adapted from another professor.

Developing an ERD

Developing an ERD requires an understanding of the system and its components. Before discussing the procedure, let's look at a narrative created by Professor Harman.Consider a hospital:Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single doctor, but in rare cases they will have two.Heathcare assistants also attend to the patients, a number of these are associated with each ward.

Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time.The system must record details concerning patient treatment and staff payment. Some staff are paid part time and doctors and care assistants work varying amounts of overtime at varying rates (subject to grade).The system will also need to track what treatments are required for which patients and when and it should be capable of calculating the cost of treatment per week for each patient (though it is currently unclear to what use this information will be put).

How do we start an ERD?

1. Define Entities: these are usually nouns used in descriptions of the system, in the discussion of business rules, or in documentation; identified in the narrative (see highlighted items above).

2. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules (entity ______ entity); identified in the narrative (see highlighted items above).3. Add attributes to the relations; these are determined by the queries,and may also suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers.

What questions can we ask?a. Which doctors work in which wards?b. How much will be spent in a ward in a given week?c. How much will a patient cost to treat?d. How much does a doctor cost per week?e. Which assistants can a patient expect to see?f. Which drugs are being used?4. Add cardinality to the relations

Many-to-Many must be resolved to two one-to-manys with an additional entityUsually automatically happensSometimes involves introduction of a link entity (which will be all foreign key) Examples: Patient-Drug5. This flexibility allows us to consider a variety of questions such as:a. Which beds are free?b. Which assistants work for Dr. X?c. What is the least expensive prescription?d. How many doctors are there in the hospital?e. Which patients are family related?

6. Represent that information with symbols. Generally E-R Diagrams require the use of the following symbols:

Reading an ERD

It takes some practice reading an ERD, but they can be used with clients to discuss business rules.

These allow us to represent the information from above such as the E-R Diagram below:ERD brings out issues:Many-to-ManysAmbiguitiesEntities and their relationshipsWhat data needs to be storedThe Degree of a relationship

Now, think about a university in terms of an ERD. What entities, relationships and attributes might you consider? Look at this simplified view. There is also an example of a simplified view of an airline on that page.You can investigate more about ERDs by viewing these sources available on the Internet:E-R Diagrams, Tables and their Meaning

Entity-Relationship Diagrams

Entity-Relationship Diagrams

Entity-Relationship Diagrams

4.1 Lecture: Entity Relationship Analysis

Five Entities related to Agent

Crosswalk Exercise - ALMRS Customer with the Standard

Guidelines

Domain Analysis

ERDIAG

A primary key is a key that is unique. A primary key is used to identify a record uniquely. There is not any particular case to not have a primary key . If you want to identify your records you should have a primary key or a surrogate key(as an alternative to it) .

In reality, you should always have a primary key. A primary key is there to uniquely identify each record, as it is like other elements would be duplicated. If you had a very large amount of names of people, then it is highly likely that the same firstname or same surname or even the same full name will come up more than once. Having a primary key distinguishes them as each primary key has to be unique.

Situations where you might not use it is where you have a very defined set of values where there is guaranteed to be no duplicates, like a database that has the 12 months of the year or a list of regions that all have different names. You still could make them primary keys, but in the case of the months, it would change them into alphabetical order, which you would not want, so that would be another reason for not using a primary key. To keep them in order, you could add another field, with the values from 1 to 12 and use that field as the primary key.