1. Връзката между оригиналния документ и организацията
Може да бъде един към един, един към много и много към много. Общо взето, те са взаимоотношения един към един: т.е. двойка оригинални документи
трябва и съответства само на една същност. В специални случаи те могат да бъдат връзки едно към много или много към едно, т.е. един оригинален документ съответства на множество реалности
тяло или множество оригинални документи, съответстващи на дадено дружество. Обектът тук може да се разбира като основна таблица. След като изяснихме тази кореспонденция, проектирайте за нас
Входният интерфейс е много полезен.
〖Пример 1〗: Информацията за автобиографията на служителя съответства на три основни таблици в системата за човешки ресурси: основна информационна таблица на служителя и общество
Таблица за взаимоотношения, формуляр за работно резюме. Това е типичен пример за "един оригинален документ съответства на множество обекти".
2. Първични и външни ключове
Обикновено едно дружество не може да има нито първичен, нито външен ключ. В диаграмата E-R, обектите в листната част могат да дефинират първичния ключ,
Възможно е също така да не се дефинира първичен ключ (защото няма деца), но той трябва да има чужд ключ (защото има баща).
Дизайнът на първични и външни ключове заема важна роля в дизайна на глобалните бази данни. Когато дизайнът на глобалната база данни е завършен, съществува
Американските експерти по проектиране на бази данни казаха: "Ключове, ключове навсякъде, само ключове", това е неговият опит в проектирането на бази данни
Той също така отразява неговите силно абстрактни идеи за ядрото на информационните системи (модели на данни). Защото: първичният ключ е силно абстрактна единица, а първичният ключ е свързан с
Двойка външни ключове, която представлява връзка между обекти.
3. Природата на основната таблица
Основната таблица се различава от междинната и временната таблица, защото има следните четири характеристики:
(1) Атомност. Полетата в основната таблица вече не могат да се разлагат.
(2) Примитивност. Записите в основната таблица са записи на оригиналните данни (основните данни).
(3) Дедуктивно. Всички изходни данни могат да бъдат извлечени от данните в базовата и кодовата таблица.
(4) Стабилност. Структурата на основната таблица е относително стабилна и записите в таблицата трябва да се съхраняват дълго време.
След разбиране на естеството на основните таблици, при проектирането на бази данни основните таблици могат да се различават от междинни таблици и временни таблици.
4. Парадигмени стандарти
Връзката между основната таблица и нейните полета трябва да отговаря максимално на третата парадигма. Въпреки това, дизайните на бази данни, които отговарят на третия парадигма, често не са
Най-добрият дизайн. За да се подобри оперативната ефективност на базите данни, често е необходимо да се намали стандартът на парадигмата: съответно да се увеличи излишъкът, за да се постигне пространство за време
Целта на.
Пример 2: Съществува основна таблица за съхранение на стоки, както е показано в Таблица 1. Наличието на полето "Количество" показва, че таблицата не е проектирана да бъде удовлетворена
Третата парадигма е достатъчна, защото "количество" може да се получи чрез умножаване на "единичната цена" по "количество", което показва, че "количеството" е излишно поле. Въпреки това, увеличаване
Излишното поле "сума" може да подобри скоростта на статистиката на заявките, което е практиката на размяна на пространство за време.
В Rose 2002 има два типа предписани колони: колони с данни и изчислени колони. Колона като "сума" се нарича "изчислителна колона", и
Колони като "Единична цена" и "Количество" се наричат "колони с данни".
Таблица 1 Структура на таблицата на стоките
Име на продукта Модел на продукта Единична цена Количество
ТВ 29 инча 2 500 40 100 000
5. Разберете трите парадигми в прост език
Разбирането на трите парадигми на прост език е от голяма полза за дизайна на бази данни. В дизайна на бази данни, за да се прилагат по-добре трите парадигми, просто
Три парадигми трябва да се разбират в прост език:
Първата парадигма: 1NF е атомно ограничение върху атрибутите, което изисква атрибутите да са атомарни и вече не могат да се разлагат;
Втората парадигма: 2NF е ограничението за уникалност върху записите, изискващо записите да имат уникална идентификация, тоест уникалността на обекта;
Парадигма 3: 3NF е ограничение върху излишъкът на полета, тоест не може да се изведе поле от други полета, което изисква полето да не е излишно
。
Нито един излишен дизайн на база данни не може да го направи. Въпреки това, база данни без излишък не е непременно най-добрата база данни, понякога за да се подобри късмета
За постигане на ефективност е необходимо да се намали стандартът на парадигмата и да се запазят адекватно излишни данни. Конкретният подход е да се придържа към третата парадигма при проектирането на концептуални модели на данни
, работата по намаляване на стандарта на парадигмата се разглежда при проектирането на физическия модел на данни. Намаляването на парадигмата означава добавяне на полета, които позволяват излишък.
6. Бъдете добри в идентифицирането и правилното управление на връзките между много към много
Ако има връзка много към много между две субекти, тази връзка трябва да бъде елиминирана. Начинът да се елиминира е да се добави трета реална стойност между двете
тяло. По този начин това, което преди беше връзка много към много, сега се превърна в две връзки един към много. Атрибутите на оригиналните две същности трябва да бъдат разумно разпределени
Отиди при трите същности. Третият обект тук е по същество по-сложна връзка, която съответства на основна таблица. Общо взето, числа
Инструментът за проектиране на библиотеки не може да разпознава връзки много към много, но може да обработва връзки много към много.
Пример 3: В "Библиотечната информационна система" "книгата" е обект, а "читателят" също е същност. Тези две същности са едни и същи
Връзката между книгите е типична "много към много": една книга може да бъде заета от няколко читатели в различно време, а един читател може да заеме повече
Тази книга. За тази цел трябва да се добави трето дружество между двете, наречено "заемане и връщане на книги", чиито свойства са: заемане на време и заемане
Има и лого (0 означава заемане на книга, 1 означава връщане на книга), освен това трябва да има и два външни ключа (първичен ключ на "книга" и първичен ключ на "четец"), така че
Свързва се с "книги" и "читатели".
7. Метод на стойността на първичния ключ PK
PK е инструмент за свързване между таблици за програмисти, който може да представлява низ от числа без физическо значение, който автоматично се добавя от програмата към 1. Да
е физически значимо име на полето или комбинация от имена на полета. Но първото е по-добро от второто. Когато PK е комбинация от имена на полета, предложи номер на полето
Не бройте прекалено много, тъй като индексът не само заема много място, но и забавя темпото.
8. Осигурете правилната излишност на данни
Повторението на първични и външни ключове в множество таблици не е концепция за излишък на данни и много хора не са наясно с това
。 Повторението на неключови полета е излишък на данните! И това е ниско ниво на излишък, тоест повтаряща се излишност. Разширената излишност не е базирана на терен
Многократно, но производни на полета.
Пример 4: Трите полета "единична цена, количество и количество" в продукта, "количество" се извежда от "единичната цена", умножена по "количество"
Това е излишък, и то е вид напреднала излишност. Целта на излишъка е да увеличи скоростта на обработка. Само ниско ниво на излишък ще увеличи броя
несъответствие на данните, защото едни и същи данни могат да бъдат въвеждани многократно от различни часове, места и роли. Затова застъпваме напреднала излишност (pie
излишък по природа), и се противопоставя на ниско ниво излишък (повтаряща се излишност).
9. Няма стандартен отговор за E--R диаграми
Няма стандартен отговор на E--R диаграмата на информационна система, защото нейният метод на проектиране и рисуване не са уникални, стига да обхващат бизнеса, необходим за системата
Обхватът и функционалното съдържание са възможни. Вместо това е необходимо да се модифицира диаграмата E--R. Въпреки че няма единен стандартен отговор, това не означава, че може да бъде произволен
Дизайн. Критериите за добра E-R диаграма са: ясна структура, кратка асоциация, умерен брой обекти, разумно разпределение на атрибути и липса на ниско ниво излишък.
10. Техниките за преглед са полезни при проектирането на бази данни
За разлика от основните таблици, кодовите таблици и междинните таблици, изгледите са виртуални таблици, които зависят от реалните таблици на източника на данни, за да съществуват. Мненията са за програмисти
Прозорецът, използващ базата данни, е форма на синтез на базови таблици, метод за обработка на данни и вид поверителност на потребителските данни
означава. За да се извърши сложна обработка, да се увеличи скоростта на изчисленията и да се спести място за съхранение, дълбочината на визуализацията обикновено не трябва да надвишава три слоя. Около три етажа
Ако изгледът все още не е достатъчен, трябва да дефинирате временна таблица върху изгледа и след това да дефинирате изглед върху временната таблица. По този начин дълбочината на гледката се определя многократно
Няма ограничения.
За определени информационни системи, свързани с национални политически, икономически, технологични, военни и сигурностни интереси, ролята на възгледите е още по-важна. Тези
След като физическият дизайн на основната таблица на системата е завършен, първият слой от изгледи веднага се установява върху основната таблица, а броят и структурата на този изглед на слоя са същите като тези на основната таблица
Броят и структурата са абсолютно еднакви. И е постановено, че всички програмисти имат право да оперират само на гледната точка. Само администраторът на базата данни, с
"Ключът за безопасност", държан от няколко служители, може да се управлява директно на основната маса. Читателите са поканени да се запитат: защо е така?
11. Междинни таблици, оператори и временни таблици
Междинната таблица е таблица, която съхранява статистики, предназначена е за съхранение на данни, изходни отчети или резултати от заявки, и понякога няма първичен ключ с
външни ключове (с изключение на хранилища за данни). Временните таблици са проектирани от програмисти да съхраняват временни записи за лична употреба. Базовата и междинната таблица се поддържат от DBA
Временните таблици се поддържат автоматично от самия програмист.
12. Ограниченията на целостта се проявяват в три аспекта
Целостта на домейна: Използвайте Check за реализиране на ограничения, а в инструмента за проектиране на база данни има Ch при дефиниране на диапазона на стойностите на полето
ECK бутон, чрез който се дефинира градът на стойността на полето.
Референтна цялост: Реализирано с PK, FK и тригери на ниво таблица.
Потребителски дефинирана цялост: Това са някои бизнес правила, които се реализират чрез съхранени процедури и тригери.
13. Методът за предотвратяване на пачването на дизайна на база данни е принципът "три по-малко"
(1) Колкото по-малко таблици има в една база данни, толкова по-добре. Само ако броят на таблиците се намали, може да се каже, че E-R диаграмата на системата е малка и фина, и тя се премахва
Дублиращите се и излишни обекти формират висока степен на абстракция на обективния свят, а систематичната интеграция на данни се извършва, за да се предотврати дизайнът на пачове;
(2) Колкото по-малко полета в таблицата комбинират първични ключове, толкова по-добре. Поради ролята на първичния ключ, единият е да изгражда индекса на първичния ключ, а другият служи като подтаблица
външни ключове, така че броят на полетата в комбинацията от първични ключове е намален, което не само спестява време за изпълнение, но и спестява място за съхранение на индекса;
(3) Колкото по-малко полета има в таблицата, толкова по-добре. Само малък брой полета показва, че няма дублиране на данни в системата
Има малко излишък на данните, а по-важното е, че читателите се насърчават да се научат да "сменят редове", което предотвратява привличането на полета в основната таблица на подтаблицата
, оставяйки много свободни полета в основната таблица. Т.нар. "ред за промяна на колона" е за изваждане на част от съдържанието на основната таблица и изграждане на отделна
Под-таблица. Този метод е много прост, някои хора просто не свикват с него, не го възприемат и не го прилагат.
Практическият принцип на проектирането на бази данни е да се намери правилният баланс между излишък на данни и скорост на обработка. "Трима по-малко" е цялостен преглед
Мисълта, всеобхватните възгледи, не могат да изолират определен принцип. Принципът е относителен, а не абсолютен. Принципът "още трима" определено е грешен. Опитай
Помислете: Ако се покрие същата функция на системата, диаграмата E--R с 100 обекта (общо 1 000 атрибута) определено е по-добра от диаграмата E--R с 200 обекта (общо 2 000 атрибута)
E-R диаграмата е много по-добра.
Застъпването на принципа "три по-малко" е да позволи на читателите да се научат да използват технологията за проектиране на бази данни за систематична интеграция на данни. Стъпките за интеграция на данни са насочени до:
Файловата система е интегрирана в приложена база данни, базата данни за приложения е интегрирана в тематична база данни, а тематичната база данни е интегрирана в глобална цялостна база данни.
Колкото по-висока е степента на интеграция, толкова по-силно е споделянето на данни и толкова по-малко информационни острови има
Броят на първичните ключове и броят на атрибутите ще бъдат по-малки.
Целта на застъпването на принципа "три по-малко" е да се предотврати използването на технология за пачване на читатели за постоянно добавяне, изтриване и модифициране на базата данни, с цел създаване на корпоративни данни
Библиотеката се е превърнала в "купчина боклук" от произволно проектирани таблици на бази данни или "бъркотия" от таблици на бази данни, и накрая причинява основните таблици и поколения в базата данни.
Кодовите таблици, междинните таблици и временните таблици са претрупани и безбройни, което води до невъзможност да се поддържат и парализират информационните системи на предприятията и институциите.
Принципът "още три" може да се приложи от всеки, което е заблудата на "метода на пачване" за проектиране на бази данни. Принципът на "трима по-малко"
Това е принцип на по-малко, но фино, което изисква високи умения за проектиране на бази данни и изкуство, което не всеки може да направи, защото този принцип е елиминиран
Теоретичната основа за проектиране на базата данни чрез "метода на пачиране".
14. Начини за подобряване на ефективността на работата на базата данни
При дадените хардуерни и софтуерни условия на системата, методите за подобряване на оперативната ефективност на базата данни са:
(1) При физическия дизайн на базата данни да се намали парадигмата, да се увеличи излишъкът, да се използва по-малко тригери и да се използват повече съхранени процедури.
(2) Когато изчислението е много сложно и броят на записите е много голям (например 10 милиона), комплексното изчисление първо трябва да бъде извън базата данни
След като методът на файловата система бъде изчислен и обработен на език C++, той най-накрая се добавя в таблицата. Това е опитът в проектирането на телекомуникационни системи за фактуриране.
(3) Ако се установи, че една таблица съдържа твърде много записи, като повече от 10 милиона, таблицата трябва да бъде разделена хоризонтално. Практиката на хоризонтална сегментация е:
Разделете записа в таблицата хоризонтално на две таблици въз основа на определена стойност на първичния ключ PK на таблицата. Ако се установи, че една таблица има твърде много полета, например превишаване
Осемдесет, масата е разделена вертикално, а оригиналната маса е разделена на две маси.
(4) Системна оптимизация на системата за управление на бази данни за СУБД, тоест оптимизация на различни системни параметри, като броя на буферите.
(5) При използване на SQL език, ориентиран към данни, за програмиране, се опитайте да възприемете оптимизационни алгоритми.
Накратко, за да се подобри оперативната ефективност на базата данни, необходимо е оптимизиране на системата за бази данни, дизайна на базата данни и изпълнението на програмата
, тези три нива работят усилено едновременно.
Горните четиринадесет умения постепенно се обобщават от много хора в голям брой практики за анализ и дизайн на бази данни. За тези преживявания
Читателите не трябва да бъдат строги или рутинни, а да усвояват и разбират, да търсят истината от фактите и да овладяват гъвкаво. И постепенно го прави: изпращай заявлението
изложба, приложение в разработката.
|
Публикувано в 9.04.2015 г. 21:00:54 ч.
|
|
|
