Главная » C# » Отношения баз данных Visual C# (Sharp)

0

В то время как отношения являются мощной методикой, они также могут чрезвайно усложнить задачу. Чтобы упростить структуру таблицы, мы можем разбить ее на две (или  больше) таблицы и создать отношение между  ними. Этот процесс называется  нормализацией  (http://en.wikipedia.org/wiki/Database_normalization).

ОПРЕДЕЛЕНИЕ

Нормализация баз данных является методикой разработки таблиц реляционных баз данных,, направленной на  сведение  к  минимуму  повторяющихся данных  и  тем  самым на предохранение базы данных от определенных  типов  логических  противоречивтей. Когда в таблице имеется несколько экземпляров одного и того же элемента иормации, то существует возможность, что при обновлении таблицы не сохранится единообразие этих экземпляров, и это повлечет за собой нарушение  целостности данных. Достаточно  нормализованная таблица  не  является уязвимой  со  стороны  это рода проблем, т. к. ее структура изначально предотвращает сохранение в ней пторяющейся   информации.

Например, отношение между лотерейным билетом в одной таблице и выигравшим человеком в другой таблице является нормализацией. Так как данные о выиграем билете и данные о его владельце хранятся в отдельных таблицах, то общая структура  данных  является  более  эффективной  с  точки  зрения  сопровождения и производительности.

Отношения между таблицами являются формой ссылок, когда одна таблица указает, что определенная информация в ней ссылается на информацию в другой таице. Это достигается путем создания перекрестных ссылок между определенными полями в обеих таблицах.

Пример с лотерейными билетами представляет интерес из-за отношений между лотерейными розыгрышами и владельцами выигравших билетов, которые  могут быть следующих двух типов:

•   один   розыгрыш    с    несколькими   выигравшими   —   в    оди н    розыгры ш     нескольк о     че-

ловек могут иметь билеты с выигравшими номерами;

•   один    выигравший    на   несколько   розыгрышей  —   хот я    тако е    развити е     и     маловеро -

ятно, теоретически один человек может выиграть несколько розыгрышей.

В примере с файлом отношение было "один выигравший на несколько розыгрей". Скорее всего, вы не видите здесь этого типа отношения, а думаете, что это отношение "один выигравший на один розыгрыш". Но посмотрите на эти результы розыгрышей, где Джек выиграл дважды:

2000.05.31 никто 5 6 13 23 25 37 43 2000.06.03 Джек 7 10 11 18 32 41 5 2000.06.07 никто 15 23 24 28 38 39 45

2000.06.10 Джек 1 3 12 23 29 33 27

2000.06.14 никто 2 4 13 19 39 45 26

2000.06.17 никто 3 8 17 19 21 25 35

Как видим, таблица розыгрышей имеет возможность содержать одного и того же выигравшего больше, Чем один раз, откуда следует, что отношение "один выиавший на несколько розыгрышей" является возможным. Чтобы добавить отношие "один розыгрыш с несколькими выигравшими", таблицу необходимо модифировать следующим образом:

2000.05.31 никто     5 6 13 23 25 37 43

2000.06.03 Джек Ддилл 7 10 11 18 32 41 5 2000.06.07 никто      15 23 24 28 38 39 45

2000.06.10 Джек 1 3 12 23 29 33 27

2000.06.14 никто 2 4 13 19 39 45 26

2000.06.17 никто 3 8 17 19 21 25 35

Здесь в другом  поле указывается второй владелец билета с выигрышной комбинией номеров — Джилл. Но добавление другого поля нарушает всю структуру таицы и намного усложняет обработку данных, т. к. при анализе строки необходимо выполнять проверку на наличие дополнительного поля. Также нарушается аккатная структура, что явно неправильно.

При использовании текстовых файлов, в таком случае можно было бы создать трий файл, связывающий перекрестными ссылками владельцев выигравших билетов с датами розыгрышей, которые они выиграли. При таком подходе файлу лотереых номеров возвращается его первоначальный формат:

2 0 0 0 . 0 5 . 3 1 5 6 1 3 2 3 2 5 3 7 4 3

2 0 0 0 . 0 6 . 0 3 7 1 0 1 1 1 8 3 2 4 1 5

2 0 0 0 . 0 6 . 0 7 1 5 2 3 2 4 2 8 3 8 3 9 4 5

2000.06.10 1 3 12 23 29 33 27

2000.06.14 2 4 13 19 39 45 26

2000.06.17 3 8 17 19 21 25 35

Но  создается  файл  с таблицей  владельцев  выигравших билетов:

2000.06.03 Джек 2000.06.03 Джилл 2000.06.10 Джек

Строки таблицы выигравших содержат два поля — дату розыгрыша и имя выиавшего данный розыгрыш. Обратите внимание на отсутствие записей для розрышей без выигравших, т. е. таблица  содержит только  даты  розыгрышей,  в  котых  был  выигравший.

ПРИМЕЧАНИЕ

Данные три таблицы служат примером правильной нормализации данных. При прильной нормализации каждая таблица содержит уникальные данные. В данном прере  одна  таблица  содержит  информацию  о  выигрышных  номерах,  а  информация о  владельцах билетов с этими  номерами хранится  в другой таблице.  Таблица  номеров и таблица выигравших связаны датой,  но каждая из таблиц является самодостаточной.

Теперь рассмотрим вариант, когда владельцами выигравших билетов являются два разных человека, но с одинаковым именем. Соответствующие данные могут влядеть  таким  образом:

2000.05.31 никто

5

6

13

23

25

37

43

2000.06.03 никто

7

10

11

18

32

41

5

2000.06.07 никто

15

23

24

28

38

39

45

2000.06.10 Джек

1

3

12

23

29

33

27

2000.06.14 Джек

2

4

13

19

39

45

26

2000.06.17 никто

3

8

17

19

21

25

35

Мы  знаем,  что две  записи  с  полями Джек не  отражают одного  и того же Джека.  Тим  образом,  у  нас  имеется  проблема  с  обеспечением  однозначности.  Это  обычная проблема  реляционных  баз  данных,  и  распространенным  способом  ее  решения  яяется  присвоение  каждому  Джеку уникального  ключа.  Таким  уникальным  ключом может  быть,  например,  jack_i  и  jack_2. Но  с  использованием   jack_i   и  jack_2 имеется   проблема,   заключающаяся   в  том,   что   нам  будет  необходимо  выполнить поиск в базе данных, чтобы узнать,  имеется ли  в ней запись Джек, после  чего найти последнюю  запись  Джек. Операции  этого  рода,  как  правило,  ресурсоемкие,  и  обыо     их     следует     избегать.     Другое     решение     заключается     в     использовании предоставляемого   базой   данных   поля,   в   котором   генерируется  уникальный   ключ. Он   может   быть   номером   строки   или   идентификатором   GUID   (Globally   Unique Identifier,       глобальный       уникальный       идентификатор).       При       генерировании уникального  идентификатора  компьютером  таблица  будет  выглядеть  так: 2000.05.31 1877_ds 5 6 13 23 25 37 43 2000.06.03 1877_ds 7 10 11 18 32 41 5

458

2000..06..07

1877._ds

15

23

24

28

38

39

45

2000. 06. 10 1023._ad 1 3 12 23 29 33 27

2000..06..14 1022. 2 4 13 19 39 45 26

2000 .06..17 1877._ds 3 8 17 19 21 25 35

В этой таблице идентификаторы не дают никакого представления о владельцах вгравших билетов. Чтобы получить эту информацию, нужно взять ключ и открыть соответствующий ему файл владельца выигравшего билета. Например, чтобы  уать, кто такой l877_ds, необходимо открыть файл 1877_ds.txt, где мы узнаем, что данный розыгрыш не выиграл никто. При таком подходе процесс определения влельца выигравшего билета состоит из нескольких шагов, но реляционная база данных справляется с таким типом задач довольно эффективно.

ЗАЧЕМ     НУЖНЫ      ЭТИ      ТЫСЯЧИ     ИНТЕРФЕЙСОВ      API, БИБЛИОТЕК      И       МЕТОДИК?

В течение последних 12 лет  были  разработаны  и  выпущены  следующи е  технологии: Ope n Database Connectivity (ODBC, открытые  средства  связи  с  БД),  Remote  Data  Ob- jects  (RDO,  удаленные  объекты  данных),  Jet  Database  Engine  (механизм  СУБ Д  Jet), Data Access Objects (DAO, объекты  доступа  к  данным),  ActiveX  Data  Objects  (ADO, объекты данны х  ActiveX),  Object  Linking  and  Embedding,  Database  (OLE  DB,  связывие и встраивание объектов (для баз данных)), ADO.NE T и  Language  Integrated  Query (LINQ, язык интегрированных запросов). Это означает, что каждые  два  года  вводится новая  технология  баз  данных.  Каждой  технопогии  баз  данных  сопутствуют  бибпиотек и дл я облегчения написания кода.  В  результате  имеется  ошеломляюще е  количество способо в дл я  работы  с технологией,  которой  почти 40  пет.

Но зачем нужны все это бесчисленные способы доступа и манипупировани я базами данных? Не был о бы более  разумным  всем  разработчикам  скоординироват ь  сво и действи я и работать над созданием общего подхода  дл я  работы  с  реляционным и  бами данных ? Я не могу дать вам логически обоснованного  и  приемлемого  дл я  всех ответа  на  этот вопрос.  Но я  могу высказать свое  мнение.

Программирование  баз  данных   явпяется   скучной   работой.   Хотя   программировани е баз данны х очень важно, разработка кода СУБД — одна из самых трудоемких задач программирования, по причине спожности и просто громадного размера табпи ц баз данных. Дл я любого промышленного приложения таблиц ы с 30 полям и  — дапек о не редкость.   Разрабатывая  код  дл я  добавления,  удаления  или  модифицировани я  строки в  таблиц е  с  30  полями,  разработчик  главным  образом  старается  вычислить,  какое  пе относится к какому элементу данных. Поэтому совсем неудивительно, что  разротчики пытаются автоматизировать  свою  работу.   В  конце  концов,   намного  интереей  работать  над  обнаружением  причины   ошибки   в   многопоточном   припожении, нежеп и  над ошибкой  помещени я данных  не  в то  поле.

Други м аспектом является несоответствие между языком программировани я и релионной базой данных. Репяционная база данных рассматривает данны е  в  виде  норов. Дл я нее  не  существует  отдельных элементов  данных.  А  языки  программировия рассматривают данные , как отдельные элементы.  Даж е  в  классе  коллекции  у  нас есть отдельный класс дл я управления набором  индивидуальных  ссылок.  Таким  обром, у нас получается несовпадение технопогий, что депае т трудной  задачу  их  совмтной   работы.

Суть пробпем ы при использовании языка программировани я дл я обработки наборов данных заключается в том, как интегрировать  язык сданными .  Но  в  конце туннеля  вен свет, которы м является изменени я языков  программирования ,  такие  как  объекты UNO  (Universal  Network  Objects,  универсальные  сетевые  объекты)  и  анонимны е  меты .  Объекты  UNO  рассматриваются  в  следующей  главе.

Источник: Гросс  К. С# 2008:  Пер. с англ. — СПб.:  БХВ-Петербург, 2009. — 576 е.:  ил. — (Самоучитель)

По теме:

  • Комментарии