140-250 (IT2) / 976-250 (E-Biz2) /

140-250 (IT2) / 976-250 (E-Biz2) / 977-250 (SE2)
Database Systems
Semester 1/2015
2
Contents
• Relational Database Design
– Informal Design Guidelines for
Relation Schemas
– Functional Dependencies
– Normal Forms Based on Primary
Keys
– General Definition of Second and
Third Normal Forms
3
Informal Design Guidelines for
Relation Schemas
• Making sure that the semantics of
the attributes is clear in the schema
• Reducing the redundant
information in tuples
• Reducing the NULL values in
tuples
• Disallowing the possibility of
generating spurious tuples
4
Relational Schema: OK
5
Sample Database: OK
6
Relational Schema: Not OK
7
Sample Database: Not OK
8
Relational Schema &
Sample Database: Not OK
9
Informal Design Guidelines for
Relation Schemas
• Guideline 1
– Design a relation schema so that it is easy to
explain its meaning. Do not combine attributes
from multiple entity types and relationship types
into a single relation.
– Intuitively, if a relation schema corresponds to
one entity type or one relationship type, it is
straightforward to interpret and to explain its
meaning. Otherwise, if the relation corresponds
to a mixture of multiple entities and
relationships, semantic ambiguities will result
and the relation cannot be easily explained.
10
Informal Design Guidelines for
Relation Schemas
• Guideline 2
– Design the base relation schemas so
that no insertion, deletion, or
modification anomalies are present in
the relations.
– If any anomalies are present, note
them clearly and make sure that the
programs that update the database
will operate correctly.
11
Informal Design Guidelines for
Relation Schemas
• Guideline 2
– Insertion anomalies
• Cannot insert a project unless an employee is assigned to it.
• Cannot insert an employee unless a he/she is assigned to a
project.
– Deletion anomalies
• When a project is deleted, it will result in deleting all the
employees who work on that project.
• Alternately, if an employee is the sole employee on a project,
deleting that employee would result in deleting the
corresponding project.
– Modification anomalies
• Changing the name of project number P1 from “Billing” to
“Customer-Accounting” may cause this update to be made for
all 100 employees working on project P1.
12
Anomalies
• Insertion anomalies
– We tried to insert data in a record that does not exist at
all.
• Deletion anomalies
– We tried to delete a record, but parts of it was left
undeleted because of unawareness, the data is also
saved somewhere else.
• Modification anomalies
– If data items are scattered and are not linked to each
other properly, then it could lead to strange situations.
• For example, when we try to update one data item having its
copies scattered over several places, a few instances get
updated properly while a few others are left with old values.
Such instances leave the database in an inconsistent state.
13
Informal Design Guidelines for
Relation Schemas
• Guideline 3
– As far as possible, avoid placing attributes in a base
relation whose values may frequently be NULL.
– If NULLs are unavoidable, make sure that they apply
in exceptional cases only and do not apply to a
majority of tuples in the relation.
• The attribute does not apply to this tuple.
– For example, Visa_status may not apply to U.S. students.
• The attribute value for this tuple is unknown.
– For example, the Date_of_birth may be unknown for an
employee.
• The value is known but absent; that is, it has not been
recorded yet.
– For example, the Home_Phone_Number for an employee may
exist, but may not be available and recorded yet.
14
Informal Design Guidelines for
Relation Schemas
• Guideline 4
– Design relation schemas so that they can
be joined with equality conditions on
attributes that are appropriately related
(primary key, foreign key) pairs in a way
that guarantees that no spurious tuples are
generated.
– Avoid relations that contain matching
attributes that are not (foreign key, primary
key) combinations because joining on such
attributes may produce spurious tuples.
15
Spurious Tuples
16
Summary and Discussion of
Design Guidelines
• The problems which can be detected without
additional tools of analysis, are as follows:
– Anomalies that cause redundant work to be done
during insertion into and modification of a relation,
and that may cause accidental loss of information
during a deletion from a relation
– Waste of storage space due to NULLs and the
difficulty of performing selections, aggregation
operations, and joins due to NULL values
– Generation of invalid and spurious data during
joins on base relations with matched attributes that
may not represent a proper (foreign key, primary
key) relationship
17
Functional Dependencies
• A functional dependency is a constraint between two sets of
attributes from the database.
• This means that the values of the Y component of a tuple in r
depend on, or are determined by, the values of the X component;
• The values of the X component of a tuple uniquely (or
functionally) determine the values of the Y component.
• There is a functional dependency from X to Y, or that Y is
functionally dependent on X.
– The abbreviation for functional dependency is FD or f.d.
– The set of attributes X is called the left-hand side of the FD, and Y is
called the right-hand side.
18
Functional Dependencies
• Determinant --> Dependency
– 1:1
• Std_ID --> Std_Name
– 1:N
• Std_ID --> FirstName, LastName, BirthDate
– 2Way
• Std_ID --> Std_Pin
• Std_Pin --> Std_ID
• Std_ID Std_Pin
– N:1
• Std_ID, Course_ID --> Room
19
Normal Forms Based on
Primary Keys
• Normalization of data
– A process of analyzing the given relation schemas based on
their FDs and primary keys to achieve the desirable properties
of
• (1) minimizing redundancy and
• (2) minimizing the insertion, deletion, and update anomalies
– The normalization procedure provides database designers
with the following:
• A formal framework for analyzing relation schemas based on their
keys and on the functional dependencies among their attributes
• A series of normal form tests that can be carried out on individual
relation schemas so that the relational database can be normalized
to any desired degree
• Denormalization
– The process of storing the join of higher normal form relations
as a base relation, which is in a lower normal form.
20
Normalization
• The process of efficiently organizing data in a
database. There are two goals of the normalization
process:
– eliminating redundant data (for example, storing the
same data in more than one table) and
– ensuring data dependencies make sense (only storing
related data in a table).
• Both of these are worthy goals as they reduce the
amount of space a database consumes and ensure
that data is logically stored.
• Normalization is a method to remove all these
anomalies and bring the database to a consistent
state.
21
Normal Forms Based on
Primary Keys
• Key
– {Ssn} is a key for EMPLOYEE
• Superkeys
– {Ssn}, {Ssn, Ename}, {Ssn, Ename, Bdate}, and any set of attributes that includes
Ssn are all superkeys.
• Candidate key
– If a relation schema has more than one key, each is called a candidate key.
– Primary key
• One of the candidate keys is arbitrarily designated to be the primary key,
– Secondary key
• and the others are called secondary keys.
• Prime attribute
– An attribute of relation schema R is called a prime attribute of R if it is a member of
some candidate key of R.
• Both Ssn and Pnumber are prime attributes of WORKS_ON.
• Nonprime attribute
– An attribute is called nonprime if it is not a prime attribute—that is, if it is not a
member of any candidate key
• Other attributes of WORKS_ON are nonprime.
22
Functional Dependency
• Trivial Functional Dependency
• Full Functional Dependency
• Transitive Dependency
• Multivalued Dependency
23
Functional Dependency
• Saying that there is a dependency between
attributes in a table is the same as saying that there
is a functional dependency between those attributes.
• If there is a dependency in a database such that
attribute B is dependent upon attribute A, you would
write this as “A -> B”.
– For example, In a table listing employee characteristics
including Social Security Number (SSN) and name, it can
be said that name is dependent upon SSN (or SSN ->
name) because an employee's name can be uniquely
determined from their SSN.
– However, the reverse statement (name -> SSN) is not
true because more than one employee can have the
same name but different SSNs.
24
Trivial Functional Dependencies
• occurs when you describe a functional
dependency of an attribute on a collection of
attributes that includes the original attribute.
For example, “{A, B} -> B” is a trivial functional
dependency, as is “{name, SSN} -> SSN”.
• This type of functional dependency is called
trivial because it can be derived from common
sense. It is obvious that if you already know
the value of B, then the value of B can be
uniquely determined by that knowledge.
25
Full Functional Dependency
• occurs when you already meet the
requirements for a functional dependency
and the set of attributes on the left side of
the functional dependency statement
cannot be reduced any farther.
– For example, “{SSN, age} -> name” is a
functional dependency, but it is not a full
functional dependency because you can
remove age from the left side of the
statement without impacting the dependency
relationship.
26
Transitive Dependency
• occur when there is an indirect
relationship that causes a
functional dependency.
– For example,
”A -> C” is a transitive
dependency when it is true only
because both “A -> B” and “B -> C”
are true.
27
Multivalued Dependency
• occur when the presence of one or more
rows in a table implies the presence of one
or more other rows in that same table.
– For example, imagine a car company that
manufactures many models of car, but always
makes

ผลลัพธ์ (ไทย) 1:

140-250 (IT2) 976-250 (E-Biz2) / / 977-250 (SE2)ระบบฐานข้อมูลภาคเรียนที่ 1/20152เนื้อหา•การออกแบบฐานข้อมูลเชิงสัมพันธ์-ออกแบบเป็นแนวทางสำหรับการแบบแผนความสัมพันธ์– อ้างอิงทำงาน– แบบฟอร์มปกติตามหลักคีย์– นิยามที่สองทั่วไป และรูปแบบปกติที่สาม3แนวทางการออกแบบไม่เป็นทางการแบบแผนความสัมพันธ์•การตรวจสอบที่ความหมายของแอตทริบิวต์ถูกล้างใน schema•ลดการซ้ำซ้อนข้อมูลใน tuples•ลดค่า NULLtuples•ไม่อนุญาตให้สามารถสร้าง tuples เก๊4แผนที่เกี่ยวข้อง: ตกลง5ตัวอย่างฐานข้อมูล: ตกลง6เค้าร่างเชิง: ไม่ตกลง7ฐานข้อมูลตัวอย่าง: ไม่ตกลง8เค้าร่างเชิงและฐานข้อมูลตัวอย่าง: ไม่ตกลง9แนวทางการออกแบบไม่เป็นทางการแบบแผนความสัมพันธ์•ผลงาน 1-ออกแบบแบบแผนความสัมพันธ์เพื่อให้ง่ายต่อการอธิบายความหมาย รวมแอตทริบิวต์ชนิดเอนทิตี้และความสัมพันธ์ชนิดหลายเป็นความสัมพันธ์ทางเดียว-สังหรณ์ใจ ถ้าแบบแผนความสัมพันธ์ที่สอดคล้องกับชนิดเอนทิตีหรือความสัมพันธ์ชนิดหนึ่ง เป็นตรงไปตรงมา เพื่อตีความ และอธิบายความความหมาย อื่น ๆ ถ้าความสัมพันธ์ทางตรงการผสมผสานของหลายเอนทิตี และความสัมพันธ์ ความหมาย ambiguities จะทำได้และความสัมพันธ์ที่ไม่สามารถอธิบายได้10แนวทางการออกแบบไม่เป็นทางการแบบแผนความสัมพันธ์•ผลงาน 2-ออกแบบแผนความสัมพันธ์พื้นฐานดังนั้นที่ไม่แทรก ลบ หรือแก้ไขความผิดอยู่ในความสัมพันธ์– หมายเหตุหากมีความผิดใด ๆให้ชัดเจน และแน่ใจว่าการโปรแกรมที่ปรับปรุงฐานข้อมูลจะทำต่อหรือไม่11แนวทางการออกแบบไม่เป็นทางการแบบแผนความสัมพันธ์•ผลงาน 2– แทรกความผิด•ไม่สามารถแทรกโครงการเว้นแต่เป็นกำหนดพนักงานให้•ไม่สามารถใส่พนักงานจนกว่าเขากำหนดให้เป็นโครงการ– ลบความผิด•เมื่อลบโครงการ มันจะทำการลบทั้งหมดพนักงานที่ทำงานในโครงการนั้น•สลับ ถ้าพนักงาน พนักงานแต่เพียงผู้เดียวในโครงการลบจะส่งผลลบโครงการที่สอดคล้องกัน-แก้ไขความผิด•เปลี่ยนชื่อหมายเลขโครงการ P1 จาก "เรียกเก็บเงิน""บัญชีลูกค้า" อาจทำให้เกิดการปรับปรุงนี้จะทำการพนักงาน 100 ทั้งหมดที่ทำโครงการ P112ความผิด•แทรกความผิด-เราพยายามที่จะแทรกข้อมูลในระเบียนที่มีอยู่ในทั้งหมด•การลบความผิด-เราพยายามที่จะลบระเบียน แต่บางส่วนที่เหลือยกเลิกลบ เพราะ unawareness ข้อมูลเป็นบันทึกแฟนตาซี•แก้ไขสิ่งผิดวิสัย– ถ้ารายการข้อมูลที่อยู่กระจัดกระจาย และไม่ เชื่อมโยงกับแต่ละอื่น ๆ ได้อย่างถูกต้อง แล้วอาจทำสถานการณ์แปลก•ตัวอย่าง เมื่อเราพยายามปรับปรุงข้อมูลหนึ่งมีสินค้าของรับอินสแตนซ์กี่สำเนากระจายหลายจุดการปรับปรุงอย่างถูกต้องในขณะที่บางคนจะเหลือไว้กับค่าเก่ากรณีดังกล่าวออกจากฐานข้อมูลในสถานะไม่สอดคล้องกัน13แนวทางการออกแบบไม่เป็นทางการแบบแผนความสัมพันธ์•ผลงาน 3– เป็นเท่าที่เป็นไปได้ ซ่อนแอตทริบิวต์ในฐานความสัมพันธ์ที่มีค่าบ่อยอาจเป็น NULL-ถ้า NULLs จะหลีกเลี่ยงไม่ได้ ให้แน่ใจว่า พวกเขาใช้ในกรณีพิเศษเท่านั้น และไม่ใช้กับการส่วนใหญ่ของ tuples ในความสัมพันธ์•แอตทริบิวต์ไม่สามารถใช้กับทูเพิลนี้-ตัวอย่าง Visa_status อาจไม่สามารถใช้กับนักเรียนในสหรัฐอเมริกา•ค่าแอตทริบิวต์ของทูเพิลนี้ไม่รู้จัก– ตัวอย่าง Date_of_birth อาจทราบสาเหตุของการพนักงาน•ค่าเป็นหนึ่งแต่ขาดงาน กล่าวคือ มันไม่ได้บันทึกได้-ตัวอย่าง Home_Phone_Number สำหรับพนักงานอาจมีอยู่ แต่อาจไม่ว่าง และบันทึกไว้ได้ด้วย14แนวทางการออกแบบไม่เป็นทางการแบบแผนความสัมพันธ์•ผลงาน 4-ออกแบบแบบแผนความสัมพันธ์เพื่อให้พวกเขาสามารถได้ร่วมกับเงื่อนไขความเสมอภาคในแอตทริบิวต์ที่เกี่ยวข้องอย่างเหมาะสม(คีย์หลัก คีย์) คู่แบบที่รับประกัน tuples เก๊ไม่เป็นที่สร้างขึ้น-หลีกเลี่ยงความสัมพันธ์ที่ประกอบด้วยการจับคู่แอตทริบิวต์ที่ไม่ได้ (คีย์ หลักชุดคีย์) เพราะรวมกับเช่นแอตทริบิวต์อาจผลิต tuples เก๊15Tuples เก๊16สรุปและอภิปรายของแนวทางการออกแบบ•ปัญหาที่สามารถตรวจพบได้โดยไม่ต้องเครื่องมือวิเคราะห์ เพิ่มเติมมีดังนี้:– ความผิดที่ทำงานซ้ำซ้อนจะทำแทรกเป็นและปรับเปลี่ยนความสัมพันธ์และที่อาจทำให้ข้อมูลสูญหายโดยไม่ตั้งใจในระหว่างการลบจากความสัมพันธ์-พื้นที่จัดเก็บเนื่องจาก NULLs เสียและความยากของการเลือก การรวมการดำเนินงาน และรวมจากค่า NULL– สร้างข้อมูลปลอม และไม่ถูกต้องในระหว่างการบนพื้นฐานความสัมพันธ์กับคุณลักษณะที่ตรงกันที่อาจเป็นตัวแทนเหมาะสม (คีย์ หลักความสัมพันธ์ของคีย์)17หน้าที่อ้างอิง• A ทำงานคือ ข้อจำกัดระหว่างสองชุดแอตทริบิวต์จากฐานข้อมูล•หมายถึง ว่า ค่าของ Y ส่วนประกอบของทูเพิลใน rขึ้นอยู่กับ หรือถูกกำหนด โดย ค่าประกอบ X•ค่าของส่วนประกอบของทูเพิล X ไม่ซ้ำกัน (หรือมีฟังก์ชัน) กำหนดค่าประกอบ Y•มีการอ้างอิงฟังก์ชันจาก X ไป Y หรือ Y คือฟังก์ชันขึ้นอยู่กับ X–ย่ออ้างอิงหน้าที่เป็น FD หรือ f.d.– ตั้งค่าแอตทริบิวต์ X เรียกว่าด้านซ้ายของ FD และ Y คือเรียกว่าด้านขวามือ18หน้าที่อ้างอิงดีเทอร์มิแนนต์•--> การอ้างอิง– 1:1• Std_ID หอม Std_Name– 1: N• Std_ID หอม FirstName, LastName วันเกิด– 2Way• Std_ID หอม Std_Pin• Std_Pin--> Std_ID• Std_ID <> – Std_Pin-แบบ N:1• Std_ID, Course_ID--> ห้องพัก19ตามฟอร์มปกติคีย์หลัก•ฟื้นฟูข้อมูล-กระบวนการของการวิเคราะห์แบบแผนความสัมพันธ์ที่กำหนดตามFDs และคีย์หลักของพวกเขาเพื่อให้ได้คุณสมบัติต้องการของ• (1) ลดความซ้ำซ้อน และ• (2) ลดการแทรก ลบ และปรับปรุงสิ่งผิดวิสัย-ขั้นตอนฟื้นฟูช่วยให้การออกแบบฐานข้อมูลมีดังต่อไปนี้:•ยึดตามกรอบการวิเคราะห์แบบแผนความสัมพันธ์อย่างเป็นทางการคีย์อ้างอิงทำงานระหว่างคุณลักษณะและ•ชุดทดสอบฟอร์มปกติที่สามารถทำในแต่ละบุคคลแบบแผนความสัมพันธ์เพื่อให้สามารถตามปกติฐานข้อมูลเชิงสัมพันธ์ใด ๆ ที่ต้องการศึกษา• Denormalization-กระบวนการจัดเก็บรวมของความสัมพันธ์แบบฟอร์มปกติสูงเป็นความสัมพันธ์พื้นฐาน ซึ่งอยู่ในแบบปกติที่ต่ำกว่า20ฟื้นฟู•การจัดระเบียบข้อมูลได้อย่างมีประสิทธิภาพในการฐานข้อมูล มี 2 เป้าหมายของการฟื้นฟูกระบวนการ:-ขจัดข้อมูลซ้ำซ้อน (เก็บตัวอย่าง การข้อมูลเดียวกันในตารางมากกว่าหนึ่งตาราง) และ-บริการข้อมูลอ้างอิงเหมาะสม (เดียวเก็บข้อมูลที่เกี่ยวข้องในตาราง)•ทั้งสองเหล่านี้เป็นเป้าหมายที่คุ้มค่าช่วยลดการเนื้อที่ฐานข้อมูลใช้ และมั่นใจเหตุผลมีเก็บข้อมูล•ฟื้นฟูเป็นวิธีการเอาออกทั้งหมดนี้ความผิด และนำฐานข้อมูลไปที่สอดคล้องกันรัฐ21ตามฟอร์มปกติคีย์หลัก•คีย์- {Ssn } เป็นคีย์สำหรับพนักงาน• Superkeys- {Ssn }, {Ssn, Ename }, {Ssn, Ename, Bdate }, และมีชุดของคุณลักษณะที่มีSsn superkeys ทั้งหมดได้•ผู้สมัครคีย์-ถ้าแบบแผนความสัมพันธ์มีคีย์มากกว่าหนึ่ง แต่ละคือหมายเลขผู้สมัคร-คีย์หลัก•แป้นผู้หนึ่งโดยถูกกำหนดให้เป็นคีย์หลัก-คีย์รอง• และอื่น ๆ เรียกว่าคีย์รอง•นายกแอตทริบิวต์– แอตทริบิวต์ของแบบแผนความสัมพันธ์ R คือคุณลักษณะเฉพาะของ R ถ้าเป็นสมาชิกของคีย์ตัวเลือกบางอย่างของอาร์• Ssn และ Pnumber เป็นคุณลักษณะสำคัญของ WORKS_ON•แอตทริบิวต์ nonprime– แอตทริบิวต์ที่เรียกว่า nonprime ถ้าไม่มีแอททริบิวต์เฉพาะ — นั่นคือ ถ้าไม่มีสมาชิกของคีย์ใด ๆ ผู้สมัคร•คุณลักษณะอื่น ๆ ของ WORKS_ON มี nonprime22หน้าที่อ้างอิง•อ้างอิงทำงานเล็กน้อย•ผสานเชื่อมโยงกัน•อ้างอิงสกรรมกริยา•อ้างอิงที่มีหลายค่า23หน้าที่อ้างอิง•คำพูดที่มีอยู่เชื่อมโยงกันระหว่างแอตทริบิวต์ในตารางการเหมือนกับการพูดที่มีอ้างอิงการทำงานระหว่างคุณลักษณะเหล่านั้นได้•ถ้ามีการอ้างอิงในฐานข้อมูลที่แอตทริบิวต์ B ขึ้นคุณลักษณะ A คุณเขียนนี้เป็น "A -> B"-ตัวอย่าง ในตารางแสดงลักษณะของพนักงานรวมชื่อและหมายเลขประกันสังคม (SSN) สามารถจะกล่าวชื่อคือ SSN ขึ้น (หรือ SSN ->ชื่อ) เนื่องจากชื่อของพนักงานต้องไม่ซ้ำกันกำหนดจาก SSN ของพวกเขา-อย่างไรก็ตาม คำสั่งย้อนกลับ (ชื่อ -> SSN) ไม่จริงเนื่องจากมีพนักงานมากกว่าหนึ่งชื่อเดียวกันแต่ต่าง SSNs24อ้างอิงทำงานเล็กน้อย•เกิดขึ้นเมื่อคุณอธิบายการทำงานเชื่อมโยงกันของแอททริบิวต์ของชุดข้อมูลแอตทริบิวต์ที่มีแอตทริบิวต์ดั้งเดิมตัวอย่าง "{A, B }--> B" เป็นการเล็กน้อยทำงานอ้างอิง เป็น " {ชื่อ SSN } -> SSN "•อ้างอิงทำงานชนิดนี้เรียกว่าเล็กน้อยเนื่องจากมันสามารถมาจากทั่วไปความรู้สึก เป็นที่ชัดเจนว่าถ้าคุณรู้อยู่แล้วค่าของ B แล้วค่าของ B ได้โดยเฉพาะตาม25อ้างอิงทำงานเต็มรูปแบบ•เกิดขึ้นเมื่อคุณพบแล้วความต้องการสำหรับอ้างอิงการทำงานและตั้งค่าของแอตทริบิวต์บนด้านซ้ายของรายงานอ้างอิงการทำงานไม่สามารถลดได้ไกลออกไป-ตัวอย่าง, " {SSN อายุ}--> ชื่อ" เป็นการอ้างอิงที่ทำงาน แต่มันไม่เต็มอ้างอิงที่ทำงานเนื่องจากคุณสามารถอายุออกด้านซ้ายของคำสั่ง โดยไม่มีผลกระทบต่อการขึ้นต่อกันความสัมพันธ์26อ้างอิงสกรรมกริยา•เกิดขึ้นเมื่อมีการอ้อมความสัมพันธ์ที่ทำให้เกิดการการอ้างอิงที่ทำงาน-ตัวอย่าง"A -> C" เป็นคำสกรรมกริยาอ้างอิงเมื่อมันเป็นความจริงเท่านั้นเนื่องจากทั้ง "A -> B" และ "บี -> C"เป็นจริง27อ้างอิงที่มีหลายค่า•เกิดขึ้นเมื่อสถานะของหนึ่งแถวในตารางหมายถึงสถานะหนึ่งหรือแถวเพิ่มเติมอื่น ๆ ในตารางเดียวกัน-ตัวอย่าง สมมติรถบริษัทที่ผลิตรถ หลายรุ่นแต่เสมอทำให้

ผลลัพธ์ (ไทย) 2:

140-250 (IT2) / 976-250 (E-Biz2) / 977-250 (SE2)
ระบบฐานข้อมูลภาคการศึกษาที่ 1/2015 2 สารบัญ•การออกแบบฐานข้อมูลเชิงสัมพันธ์- แนวทางการออกแบบเป็นทางการสำหรับความสัมพันธ์Schemas - พึ่งพาการทำงาน- รูปแบบปกติบนพื้นฐานของหลักคีย์- ความหมายทั่วไปที่สองและที่สามปกติแบบฟอร์มที่3 เป็นทางการแนวทางการออกแบบสำหรับความสัมพันธ์ Schemas •ให้แน่ใจว่าความหมายของคุณลักษณะที่มีความชัดเจนในคี•ลดซ้ำซ้อนข้อมูลในtuples •ลดค่าเป็นศูนย์ในtuples •ไม่อนุญาตเป็นไปได้ของสร้าง tuples ปลอม4 Schema สัมพันธ์: OK 5 ฐานข้อมูลตัวอย่าง: OK 6 สัมพันธ์ Schema: ไม่ได้ตกลง7 ฐานข้อมูลตัวอย่าง: ไม่ได้ตกลง8 สัมพันธ์ Schema และฐานข้อมูลตัวอย่าง: ไม่ได้ตกลง9 ทางการแนวทางการออกแบบสำหรับความสัมพันธ์ Schemas •หลักเกณฑ์ 1 - การออกแบบสคีที่เกี่ยวข้องเพื่อ ว่ามันเป็นเรื่องง่ายที่จะอธิบายความหมายของมัน ไม่รวมคุณลักษณะประเภทนิติบุคคลหลายและประเภทความสัมพันธ์เป็นความสัมพันธ์เพียงครั้งเดียว. - สังหรณ์ใจถ้าเค้าร่างความสัมพันธ์สอดคล้องกับประเภทหนึ่งนิติบุคคลหรือประเภทความสัมพันธ์แบบหนึ่งก็คือตรงไปตรงมาในการตีความและอธิบายของความหมาย มิฉะนั้นถ้าความสัมพันธ์สอดคล้องส่วนผสมของหน่วยงานหลายและความสัมพันธ์คลุมเครือความหมายจะมีผลและมีความสัมพันธ์ที่ไม่สามารถอธิบายได้อย่างง่ายดาย. 10 แนวทางการออกแบบเป็นทางการสำหรับความสัมพันธ์ Schemas •แนวทาง 2 - การออกแบบแบบแผนความสัมพันธ์ฐานเพื่อว่าจะไม่มีการแทรกลบหรือความผิดปกติของการปรับเปลี่ยนที่มีอยู่ในความสัมพันธ์. - หากความผิดปกติใด ๆ ที่มีอยู่ทราบได้อย่างชัดเจนและทำให้แน่ใจว่าโปรแกรมที่ปรับปรุงฐานข้อมูลจะทำงานได้อย่างถูกต้อง. 11 เป็นทางการแนวทางการออกแบบสำหรับความสัมพันธ์ Schemas •แนวทาง 2 - ความผิดปกติแทรก•ไม่สามารถใส่โครงการเว้นแต่พนักงานที่ได้รับมอบหมายไป. •ไม่สามารถใส่พนักงานเว้นแต่เขา / เธอจะได้รับมอบหมายให้โครงการ. - ความผิดปกติการลบ•เมื่อโครงการถูกลบก็จะมีผลในการลบทั้งหมดที่พนักงานที่ทำงานในโครงการที่. • อีกวิธีหนึ่งคือถ้าพนักงานเป็นพนักงาน แต่เพียงผู้เดียวในโครงการการลบการทำงานของพนักงานที่จะส่งผลในการลบโครงการที่สอดคล้องกัน. - ความผิดปกติของการปรับเปลี่ยน•การเปลี่ยนชื่อของจำนวนโครงการP1 จาก "การเรียกเก็บเงิน" เพื่อ"ลูกค้าบัญชี" อาจทำให้เกิดการปรับปรุงนี้เพื่อ จะทำให้ทุกคน100 คนที่ทำงานในโครงการ P1. 12 ผิดปกติ•ความผิดปกติแทรก- เราพยายามที่จะแทรกข้อมูลในการบันทึกที่ไม่ได้อยู่ที่ทั้งหมด. •ความผิดปกติการลบ- เราพยายามที่จะลบระเบียน แต่บางส่วนของมันถูกทิ้งลบเพราะไม่รู้ข้อมูลนอกจากนี้ยังมีการบันทึกไว้ที่อื่น. •ความผิดปกติของการปรับเปลี่ยน- หากรายการข้อมูลจะกระจายและไม่ได้เชื่อมโยงกับแต่ละอื่นๆ ที่ถูกต้องแล้วก็อาจนำไปสู่สถานการณ์ที่แปลก. •ตัวอย่างเช่นเมื่อเราพยายามที่จะปรับปรุงรายการข้อมูลหนึ่ง มีของสำเนากระจายไปทั่วหลายสถานที่ไม่กี่กรณีได้รับการปรับปรุงอย่างถูกต้องในขณะที่บางคนอื่นๆ ที่เหลือมีค่าเก่า. กรณีดังกล่าวออกจากฐานข้อมูลในสภาวะที่ไม่. 13 เป็นทางการแนวทางการออกแบบสำหรับความสัมพันธ์ Schemas •แนวทาง 3 - เท่าที่เป็นไปได้ หลีกเลี่ยงการวางคุณลักษณะในฐานความสัมพันธ์ที่มีค่าบ่อยอาจเป็นโมฆะ. - หาก NULLs จะหลีกเลี่ยงไม่ให้แน่ใจว่าพวกเขาใช้ในกรณีพิเศษเท่านั้นและไม่นำไปใช้กับส่วนใหญ่ของtuples ในความสัมพันธ์. •คุณลักษณะที่ใช้ไม่ได้กับเรื่องนี้ . tuple - ตัวอย่างเช่น Visa_status อาจใช้ไม่ได้กับนักเรียนสหรัฐ. •ค่าแอตทริบิวต์สำหรับ tuple นี้ไม่เป็นที่รู้จัก. - ตัวอย่างเช่น Date_of_birth อาจจะไม่รู้จักสำหรับพนักงาน. •ค่าที่เป็นที่รู้จักกัน แต่ขาด; นั่นคือมันไม่ได้รับการบันทึกไว้ยัง. - ตัวอย่างเช่น Home_Phone_Number สำหรับพนักงานอาจมีอยู่แต่อาจไม่สามารถใช้ได้และบันทึกไว้ยัง. 14 เป็นทางการแนวทางการออกแบบสำหรับความสัมพันธ์ Schemas •แนวทาง 4 - แบบแผนความสัมพันธ์ได้รับการออกแบบเพื่อให้พวกเขาสามารถจะร่วมกับเงื่อนไขความเท่าเทียมกันในคุณลักษณะที่เกี่ยวข้องอย่างเหมาะสม(คีย์หลักต่างประเทศที่สำคัญ) คู่ในทางที่รับประกันว่าtuples ปลอมไม่ถูกสร้างขึ้น. - หลีกเลี่ยงความสัมพันธ์ที่มีการจับคู่คุณลักษณะที่ไม่ได้(คีย์ต่างประเทศหลักที่สำคัญ) รวมกันเพราะการเข้าร่วม ดังกล่าวคุณลักษณะอาจtuples ปลอม. 15 เก๊ Tuples 16 สรุปและอภิปรายเกี่ยวกับแนวทางการออกแบบ•ปัญหาที่สามารถตรวจพบได้โดยไม่ต้องมีเครื่องมือเพิ่มเติมของการวิเคราะห์มีดังนี้: - ความผิดปกติที่ทำให้เกิดการทำงานซ้ำซ้อนที่จะทำในช่วงแทรกเข้าและการเปลี่ยนแปลงของความสัมพันธ์, และที่อาจทำให้เกิดการสูญเสียจากอุบัติเหตุของข้อมูลในระหว่างการลบจากความสัมพันธ์- เสียของพื้นที่จัดเก็บเนื่องจากการ NULLs และความยากลำบากในการดำเนินการเลือกการรวมการดำเนินงานและร่วมเนื่องจากการค่าเป็นศูนย์- การสร้างข้อมูลที่ไม่ถูกต้องและปลอมในระหว่างการเข้าร่วมเกี่ยวกับความสัมพันธ์กับฐานที่ตรงกับคุณลักษณะที่อาจจะไม่เป็นตัวแทนที่เหมาะสม(คีย์ต่างประเทศหลักที่สำคัญ) ความสัมพันธ์17 พึ่งพาการทำงาน•พึ่งพาการทำงานเป็นข้อ จำกัด ระหว่างสองชุดของคุณลักษณะจากฐานข้อมูล. •ซึ่งหมายความว่าค่าขององค์ประกอบ Y ของ tuple ในอาขึ้นอยู่กับหรือถูกกำหนดโดยค่าขององค์ประกอบX นั้น•ค่าขององค์ประกอบX ของ tuple ไม่ซ้ำกัน (หรือหน้าที่) กำหนดค่าขององค์ประกอบวาย. •มีการพึ่งพาการทำงานจาก X คือ เป็น Y หรือว่า Y เป็นหน้าที่ขึ้นอยู่กับเอ็กซ์- ย่อพึ่งพาการทำงานเป็น FD หรือ FD - ชุดของคุณลักษณะ X เรียกว่าด้านซ้ายมือของ FD และ Y คือ. เรียกว่าด้านขวามือ18 พึ่งพาการทำงาน•ปัจจัย -> พึ่งพา - 1: 1 • Std_ID -> Std_Name - 1: ยังไม่มี• Std_ID -> ชื่อ, นามสกุล, วันเกิด- 2WAY • Std_ID -> Std_Pin • Std_Pin -> Std_ID • Std_ID <- -> Std_Pin - ไม่มี: 1 • Std_ID, Course_ID -> ห้อง19 รูปแบบปกติจากคีย์หลัก•ปกติของข้อมูล- ขั้นตอนของการวิเคราะห์แบบแผนความสัมพันธ์ที่กำหนดบนพื้นฐานของFDs ของพวกเขาและคีย์หลักเพื่อให้ได้คุณสมบัติที่พึงประสงค์ของ• ( 1) ความซ้ำซ้อนและลด• (2) ลดการแทรกลบและความผิดปกติปรับปรุง- ขั้นตอนการฟื้นฟูให้ออกแบบฐานข้อมูลดังต่อไปนี้: •กรอบอย่างเป็นทางการสำหรับการวิเคราะห์แบบแผนความสัมพันธ์บนพื้นฐานของพวกเขาคีย์และในการอ้างอิงการทำงานในหมู่คุณลักษณะของพวกเขา• ชุดของการทดสอบรูปแบบปกติที่สามารถดำเนินการในแต่ละแบบแผนความสัมพันธ์เพื่อให้ฐานข้อมูลเชิงสัมพันธ์สามารถเป็นปกติในระดับที่ต้องการ• Denormalization - ขั้นตอนการจัดเก็บเข้าร่วมของความสัมพันธ์แบบปกติที่สูงขึ้นในขณะที่ความสัมพันธ์ที่ฐานซึ่งอยู่ในรูปแบบปกติที่ต่ำกว่า. 20 ปกติ•กระบวนการของการได้อย่างมีประสิทธิภาพการจัดระเบียบข้อมูลในฐานข้อมูล มีสองเป้าหมายของการฟื้นฟูที่มีกระบวนการ: - การขจัดข้อมูลซ้ำซ้อน (ตัวอย่างเช่นการจัดเก็บข้อมูลเดียวกันมากกว่าหนึ่งตาราง) และ- การสร้างความมั่นใจการอ้างอิงข้อมูลที่ให้ความรู้สึก (เฉพาะการจัดเก็บ. ข้อมูลที่เกี่ยวข้องในตาราง) •ทั้งสองคนนี้มีความคุ้มค่า เป้าหมายที่พวกเขาลดปริมาณของกินพื้นที่ฐานข้อมูลและให้แน่ใจว่าข้อมูลจะถูกเก็บไว้มีเหตุผล. •ปกติเป็นวิธีการที่จะเอาสิ่งเหล่านี้ผิดปกติและนำฐานข้อมูลไปยังสอดคล้องรัฐ. 21 แบบฟอร์มปกติจากคีย์หลัก•กุญแจ- {SSN } เป็นกุญแจสำคัญสำหรับพนักงาน• Superkeys - {SSN}, {SSN, Ename}, {SSN, Ename, Bdate} และชุดใด ๆ ของคุณลักษณะที่มี. SSN เป็น superkeys ทั้งหมด•ที่สำคัญผู้สมัคร- หากคีมาความสัมพันธ์มีมากกว่า หนึ่งที่สำคัญแต่ละคนเรียกว่าสำคัญผู้สมัคร. - คีย์หลัก•หนึ่งในกุญแจผู้สมัครที่ถูกกำหนดโดยพลการจะเป็นคีย์หลัก- ที่สำคัญรอง•และอื่นๆ จะเรียกว่าคีย์รอง. •แอตทริบิวต์นายกรัฐมนตรี- แอตทริบิวต์ความสัมพันธ์สคี R จะเรียกว่าเป็นคุณลักษณะที่สำคัญของ R ถ้ามันเป็นสมาชิกของที่สำคัญผู้สมัครบางส่วนของอาร์•ทั้งSSN และ Pnumber เป็นคุณสมบัติที่สำคัญของ WORKS_ON. •แอตทริบิวต์ Nonprime - แอตทริบิวต์ที่เรียกว่า nonprime ถ้ามันไม่ได้เป็นนายกแอตทริบิวต์ที่เป็น ถ้ามันไม่ได้เป็นสมาชิกของที่สำคัญผู้สมัคร•คุณลักษณะอื่นๆ ของ WORKS_ON มี nonprime. 22 อยู่ที่ฟังก์ชั่น•เล็กน้อยพึ่งพาการทำงาน•เต็มฟังก์ชั่นการพึ่งพา•สกรรมกริยาพึ่งพา• Multivalued Dependency 23 พึ่งพาการทำงาน•บอกว่ามีการพึ่งพาระหว่างคุณลักษณะในตารางเป็นเช่นเดียวกับบอกว่ามี. เป็นผู้พึ่งพาการทำงานระหว่างคุณลักษณะเหล่านั้น•หากมีการพึ่งพาในฐานข้อมูลดังกล่าวว่าแอตทริบิวต์B ขึ้นอยู่กับคุณลักษณะที่คุณจะเขียนนี้เป็นระดับ"A -> B". - ยกตัวอย่างเช่น ในลักษณะตารางรายชื่อของพนักงานรวมถึงหมายเลขประกันสังคม(SSN) และชื่อก็สามารถกล่าวได้ว่าชื่อขึ้นอยู่กับSSN (หรือ SSN -> ชื่อ) เพราะชื่อของพนักงานสามารถที่ไม่ซ้ำกันกำหนดจากSSN ของพวกเขา. - แต่กลับ คำสั่ง (ชื่อ -> SSN) ไม่จริงเพราะกว่าพนักงานคนหนึ่งสามารถมีชื่อเหมือนกันแต่แตกต่างกัน SSNs. 24 การพึ่งพาการทำงานเล็กน้อย•เกิดขึ้นเมื่อคุณอธิบายการทำงานขึ้นของแอตทริบิวต์ในคอลเลกชันของคุณลักษณะที่มีแอตทริบิวต์เดิมยกตัวอย่างเช่น "{A, B} -> B" คือการทำงานเล็ก ๆ น้อย ๆการพึ่งพาที่เป็น "{ชื่อ SSN} -> SSN". •ประเภทของการพึ่งพาการทำงานนี้เรียกว่าจิ๊บจ๊อยเพราะมันจะได้รับจากการร่วมกันความรู้สึก เป็นที่ชัดเจนว่าถ้าคุณรู้อยู่แล้วว่าค่าของ B แล้วค่าของ B สามารถกำหนดไม่ซ้ำกันโดยความรู้ที่. 25 อยู่ที่ฟังก์ชั่นเต็ม•เกิดขึ้นเมื่อคุณได้ตอบสนองความต้องการสำหรับการพึ่งพาการทำงานและชุดของคุณลักษณะทางด้านซ้ายด้านข้างของงบพึ่งพาการทำงานไม่สามารถลดไกลใดๆ . - ยกตัวอย่างเช่น "{SSN อายุ} -> ชื่อ" คือการพึ่งพาการทำงานแต่ก็ไม่ได้เต็มรูปแบบพึ่งพาการทำงานเพราะคุณสามารถลบอายุจากด้านซ้ายของคำสั่งโดยไม่ส่งผลกระทบต่อการพึ่งพา. สัมพันธ์ 26 สกรรมกริยาพึ่งพา•เกิดขึ้นเมื่อมีการอ้อมความสัมพันธ์ที่เป็นสาเหตุของการพึ่งพาการทำงาน. - ยกตัวอย่างเช่น"คน -> C" เป็นสกรรมกริยาพึ่งพาเมื่อมันเป็นความจริงเพียงเพราะทั้งระดับ"A -> B "และ" B -> C "เป็นจริง. 27 Multivalued พึ่งพา•เกิดขึ้นเมื่อการปรากฏตัวของหนึ่งหรือมากกว่าแถวในตารางหมายถึงการปรากฏตัวของหนึ่งหรือมากกว่าแถวอื่นๆ ในตารางเดียวกัน. - ตัวอย่างเช่นสมมติ บริษัท รถยนต์ที่ผู้ผลิตหลายรุ่นของรถ แต่มักจะทำให้