obiekt dataset — wprowadzenie obiekty dataset służą do przechowywania danych w buforze odłączonym od źródła danych. struktura obiektu datase

Obiekt DataSet — wprowadzenie
Obiekty DataSet służą do przechowywania danych w buforze odłączonym od
źródła danych. Struktura obiektu DataSet jest podobna do struktury
relacyjnej bazy danych — obejmuje hierarchiczny model obiektów takich
jak tabele, wiersze i kolumny. Struktura ta obejmuje także
ograniczenia i relacje, zdefiniowane dla danego obiektu DataSet.
Uwaga Obiektów DataSet należy używać tylko wtedy, gdy chcemy pracować
z zestawami tabel i rekordów nie utrzymując połączenia ze źródłem
danych. Stosowanie obiektu DataSet nie zawsze jest optymalnym
rozwiązaniem dostępu do danych. Więcej informacji można znaleźć w
artykule Zalecenia dotyczące strategii dostępu do danych.
Do tworzenia obiektów DataSet i operowania na nich przydatne są
następujące fragmenty przestrzeni nazw .NET Framework.
Przestrzeń nazw Dataset

Najważniejsze części obiektów DataSet dostępne są poprzez standardowe
struktury takie jak właściwości czy kolekcje. Na przykład:
*
Klasa DataSet zawiera kolekcję Tables przechowującą informacje o
tabelach oraz kolekcję Relations, będącą zbiorem obiektów
DataRelation.
*
Klasa DataTable zawiera kolekcję Rows, reprezentującą rekordy
zgromadzone w tabeli, kolekcję Columns, zawierająca informacje o
kolumnach tabeli oraz kolekcje ChildRelations i ParentRelations,
reprezentujące relacje danej tabeli z innymi tabelami.
*
Klasa DataRow zawiera właściwość RowState, której wartość
wskazuje, czy i w jaki sposób dany rekord został zmodyfikowany od
chwili pierwszego załadowania go z bazy danych. Możliwe wartości
właściwości RowState to Deleted, Modified, New oraz Unchanged.
Obiekty Dataset, schematy i XML
Obiekt DataSet biblioteki ADO.NET jest jednym z widoków danych
(widokiem relacyjnym), które mogą być przedstawiane w postaci XML. W
Visual Studio i .NET Framework XML jest formatem przekazywania danych
dowolnego rodzaju. Właśnie dlatego obiekty DataSet są bardzo silnie
związane z XML. Związek ten umożliwia wykorzystanie następujących cech
obiektów DataSet:
*
Struktura obiektu DataSet — tabele, kolumny, relacje i
ograniczenia — może być definiowana za pośrednictwem schematu XML.
Schemat XML jest standardem opracowanym przez W3C (World Wide Web
Consortium), służącym do definiowania struktury danych XML.
Strukturę obiektu DataSet można zapisać w postaci schematu i
wczytać ją z takiej postaci za pomocą metod WriteXmlSchema oraz
ReadXmlSchema. Gdy schemat nie jest dostępny, obiekt DataSet może
przejąć go z ustrukturyzowanego w sposób relacyjny dokumentu XML,
korzystając z metody InferXmlSchema. Więcej informacji na temat
obiektów DataSet i schematów można znaleźć w artykule Schematy XML
— wprowadzenie.
*
Możliwe jest wygenerowanie klasy DataSet na podstawie schematu
tak, by poszczególne struktury danych (takie jak tabele i kolumny)
dostępne były jako składowe klasy — patrz poniższa sekcja
„Typizowane i nietypizowane obiekty DataSet”.
*
Możliwe jest wczytanie dokumentu lub strumienia XML do obiektu
DataSet za pomocą metody ReadXML oraz zapisanie obiektu DataSet w
postaci XML za pomocą metody WriteXML tego obiektu. XML jest
standardowym formatem wymiany danych pomiędzy różnymi aplikacjami,
dlatego możliwe jest wczytanie obiektu DataSet zapisanego w
postaci XML przez inną aplikację. Analogicznie, zawartość obiektu
DataSet może zostać przesłana w postaci strumienia lub dokumentu
XML tak, by mogły skorzystać z niej inne aplikacje. Może też
zostać zapisana w tym standardowym formacie.
*
Zawartość obiektu DataSet może zostać przedstawiona w postaci
widoku XML (jako obiekt XMLDataDocument). Możliwe jest wtedy
przeglądanie i modyfikowanie danych zarówno za pomocą metod
relacyjnych (poprzez obiekt DataSet) jak i metod XML. Zmiany
wprowadzone w każdym z widoków są synchronizowane automatycznie.
Typizowane i nietypizowane obiekty DataSet
Obiekty DataSet mogą być typizowane lub nietypizowane. Typizowany
obiekt DataSet to nowa klasa, zbudowana w oparciu o podstawową klasę
DataSet oraz informacje zawarte w pliku schematu XML (pliku .xsd).
Struktury danych zdefiniowane w schemacie (kolumny, tabele itd.) są
przekształcane w składowe nowej klasy DataSet.
Uwaga Więcej informacji na temat schematów obiektów DataSet można
znaleźć w artykule Schematy XML i dane.
Ponieważ klasa typizowanego obiektu DataSet dziedziczy po podstawowej
klasie obiektu DataSet, typizowany obiekt DataSet posiada pełną
funkcjonalność klasy podstawowej i może być przekazywany do metod,
które jako parametr przyjmują instancję podstawowej klasy obiektu
DataSet.
Natomiast nietypizowany obiekt DataSet nie ma wbudowanego schematu.
Tak jak typizowany obiekt DataSet, obiekt nietypizowany może zawierać
tabele, kolumny itd., jednak są one dostępne wyłącznie jako kolekcje.
Mimo tego możliwe jest ręczne utworzenie tabel i innych elementów w
nietypizowanym obiekcie DataSet i wyeksportowanie struktury DataSet w
postaci schematu za pomocą metody WriteXmlSchema.
W aplikacjach można używać obydwu typów obiektów DataSet. Zalecane
jest jednak stosowanie obiektów typizowanych, ponieważ są one lepiej
obsługiwane przez narzędzia dostępne w Visual Studio, a programowanie
z ich wykorzystaniem jest łatwiejsze i mniej podatne na błędy.
Porównanie dostępu do danych poprzez typizowane i nietypizowane
obiekty DataSet
W modelu obiektowym typizowanego obiektu DataSet tabele i kolumny są
składowymi tego obiektu. Pracując z typizowanym obiektem DataSet,
dostęp do kolumny można uzyskać tak jak w poniższym przykładzie:
' Visual Basic
' Odczytanie pola CustomerID z pierwszego rekordu
' tabeli Customers.
Dim s As String
s = dsCustomersOrders1.Customers(0).CustomerID
// C#
// Odczytanie pola CustomerID z pierwszego rekordu
// tabeli Customers.
string s;
s = dsCustomersOrders1.Customers[0].CustomerID;
Równoważny kod dla nietypizowanego obiektu DataSet:
' Visual Basic
Dim s As String
s =
CType(dsCustomersOrders1.Tables("Customers").Rows(0).Item("CustomerID"),
String)
// C#
string s = (string)
dsCustomersOrders1.Tables["Customers"].Rows[0]["CustomerID"];
Dostęp typizowany jest nie tylko czytelniejszy — jest także w pełni
wspierany przez technologię IntelliSense edytora kodu w Visual Studio.
Poza tym składnia dostępu typizowanego pozwala na sprawdzanie typów w
czasie kompilacji, co znacznie redukuje możliwość popełnienia błędów w
przypisywaniu wartości do składowych obiektu DataSet. Również dostęp
do tabel i kolumn typizowanego obiektu DataSet jest nieco szybszy,
ponieważ sposób dostępu określany jest w czasie kompilacji — bez
korzystania z kolekcji w czasie pracy aplikacji.
Typizowane obiekty DataSet mają wiele zalet, jednak w niektórych
okolicznościach nietypizowane obiekty DataSet są bardziej użyteczne.
Najprostszy przykład to niedostępność schematu dla obiektu DataSet.
Może się to zdarzyć na przykład wtedy, gdy aplikacja współpracuje z
komponentem, który zwraca obiekt DataSet i nie jest możliwe
przewidzenie z góry struktury tego obiektu. Zdarza się też, że
pracujemy z danymi, które nie mają statycznej, przewidywalnej
struktury — w takim wypadku korzystanie z typizowanych obiektów
DataSet jest niepraktyczne, ponieważ każda zmiana struktury danych
wymagałaby ponownego wygenerowania klasy typizowanego obiektu DataSet.
Ogólnie rzecz biorąc, zdarzają się sytuacje, gdy trzeba dynamicznie
wygenerować obiekt DataSet bez znajomości schematu. DataSet jest w
takich przypadkach wygodnym miejscem na przechowywanie informacji — o
ile dane mogą być reprezentowane w sposób relacyjny. Podejście to
pozwala na wykorzystanie pozostałych możliwości obiektów DataSet,
takich jak serializacja informacji w celu przekazania ich do innego
procesu lub zapisania w pliku XML.
Rozróżnianie wielkości liter w obiektach DataSet
Wielkość liter w nazwach tabel i kolumn znajdujących się w obiekcie
DataSet domyślnie nie jest rozróżniana. Do znajdującej się w obiekcie
DataSet tabeli „Customers” można odwołać się podając nazwę
„customers”. Odpowiada to konwencjom nazewniczym stosowanym w różnych
bazach danych, w tym w serwerze SQL Server — nazwy nie mogą różnić się
wyłącznie wielkością liter.
Uwaga W odróżnieniu od obiektów DataSet, w dokumentach XML wielkość
liter jest rozróżniana, a więc w nazwach elementów zdefiniowanych w
schematach wielkość liter ma znaczenie. Schemat może na przykład
zawierać tabelę o nazwie „Customers” oraz inną tabelę o nazwie
„customers”. Jeśli schemat zostanie użyty do wygenerowania klasy
DataSet, nazwy różniące się wyłącznie wielkością liter mogą spowodować
konflikt. Więcej informacji na ten temat można znaleźć w artykule
Elementy, atrybuty i typy XML.
Wielkość liter może mieć jednak wpływ na sposób interpretowania danych
w obiekcie DataSet. Na przykład podczas filtrowania danych
znajdujących się w tabeli obiektu DataSet, kryterium wyszukiwania może
zwracać różne wyniki w zależności od tego, czy porównywanie odbywa się
z rozróżnianiem czy bez rozróżniania wielkości liter. Rozróżnianie
wielkości liter podczas filtrowania, wyszukiwania i sortowania można
kontrolować za pomocą właściwości CaseSensitive obiektu DataSet.
Właściwość tę domyślnie dziedziczą wszystkie tabele znajdujące się w
obiekcie DataSet, jednak dla każdej tabeli ustawienie to może być
zmienione.
Wypełnianie obiektu DataSet danymi
Obiekt DataSet jest kontenerem, dlatego można załadować do niego dane.
Podczas wypełniania obiektu DataSet zgłaszane są różne zdarzenia,
wymuszane jest sprawdzanie ograniczeń wartości danych i tak dalej.
Więcej informacji na temat aktualizowania obiektów DataSet i problemów
z tym związanych można znaleźć w artykule Uaktualnianie obiektów
Dataset w Visual Studio .NET.
Obiekt DataSet można wypełniać na wiele sposobów:
*
Wywołanie metody Fill obiektu DataAdapter. Powoduje to wykonanie
przez obiekt DataAdapter polecenia SQL lub procedury
przechowywanej i wypełnienie tabeli obiektu DataSet wynikami
przeprowadzonej operacji. Jeśli obiekt DataSet zawiera wiele
tabel, dla każdej tabeli potrzebny jest osobny obiekt DataAdapter.
Metody Fill wszystkich tych obiektów także trzeba wywoływać
osobno.
Więcej informacji na temat wypełniania obiektów DataSet można znaleźć
w artykułach Obiekt DataAdapter — wprowadzenie oraz Tworzenie obiektów
DataAdapter. Informacje na temat wypełniania obiektu DataSet za pomocą
obiektu DataAdapter znajdują się w artykule Wypełnianie obiektu
DataSet za pomocą obiektu DataAdapter.
*
Ręczne wypełnienie tabel obiektu DataSet poprzez tworzenie
obiektów DataRow i dopisywanie ich do kolekcji Rows tabeli.
Technikę tę można stosować wyłącznie w czasie działania aplikacji
— kolekcji Rows nie da się zmieniać w czasie projektowania. Więcej
informacji można znaleźć w artykule Dopisywanie danych do tabeli.
*
Wczytanie do obiektu DataSet zawartości dokumentu lub strumienia
XML. Więcej informacji znajduje się w opisie metody ReadXml.
*
Włączenie (skopiowanie) zawartości innego obiektu DataSet. Sposób
ten jest szczególnie przydatny wtedy, gdy aplikacja otrzymuje z
różnych źródeł wiele obiektów DataSet (źródłami mogą być różne
usługi Web Service) i musi je połączyć w jeden obiekt. Więcej
informacji na ten temat można znaleźć w opisie metody
DataSet.Merge.
Bieżący rekord i nawigowanie po zawartości obiektu DataSet
Ponieważ obiekt DataSet to kontener całkowicie odłączony od źródła
danych, w obiektach DataSet — w odróżnieniu od znanych z ADO obiektów
RecordSet — nie trzeba wyróżniać i nie wyróżnia się pojęcia bieżącego
rekordu — wszystkie rekordy dostępne są równocześnie.
Ponieważ nie ma bieżącego rekordu, nie ma też właściwości wskazującej
bieżący rekord i nie ma metod ani właściwości służących do
przenoszenia się pomiędzy rekordami (znane z ADO obiekty RecordSet
wyróżniają bezwzględną pozycję rekordu i zapewniają metody pozwalające
przenosić się pomiędzy rekordami). Poszczególne tabele w obiekcie
DataSet dostępne są jako obiekty, a każda tabela udostępnia kolekcję
rekordów. Kolekcję tę można traktować tak jak każdą kolekcję — dostęp
do poszczególnych rekordów można uzyskać za pomocą indeksu kolekcji
lub za pomocą poleceń języka programowania odpowiedzialnych za obsługę
kolekcji.
Uwaga Jeśli dane z obiektu DataSet mają być dostępne poprzez kontrolki
formularza Windows Forms, to dostęp do poszczególnych rekordów możemy
przyspieszyć korzystając z architektury połączeniowej formularza.
Więcej informacji na ten temat można znaleźć w artykule Nawigowanie po
danych w formularzach Windows Forms.
Relacje pomiędzy tabelami i obiekty DataRelation
Jeśli w obiekcie DataSet znajduje się wiele tabel, to informacje
znajdujące się w poszczególnych tabelach mogą być ze sobą powiązane.
Obiekt DataSet nie zawiera sam w sobie informacji o tych powiązaniach.
Jeśli chcemy pracować z danymi znajdującymi się w tabelach
powiązanych, możemy utworzyć obiekty DataRelation, opisujące relacje
pomiędzy danymi znajdującymi się w obiekcie DataSet. Obiekty
DataRelation mogą być stosowane do pobierania rekordów potomnych
powiązanych z rodzicem lub do odnajdywania rekordu rodzica danego
rekordu potomnego.
Wyobraźmy sobie na przykład dane o klientach i zamówieniach takie jak
w bazie danych Northwind. Tabela Customers mogłaby zawierać
następujące dane:
CustomerID CompanyName City
ALFKI Alfreds Futterkiste Berlin
ANTON Antonio Moreno Taquerias Mexico D.F.
AROUT Around the Horn London
Obiekt DataSet mógłby także zawierać tabelę zamówień. Tabela Orders
zawiera pole CustomerID jako klucz obcy. Oto przykład wybranych kolumn
tabeli Orders:
OrderId CustomerID OrderDate
10692 ALFKI 10/03/1997
10702 ALFKI 10/13/1997
10365 ANTON 11/27/1996
10507 ANTON 4/15/1997
Ponieważ każdy klient może złożyć więcej niż jedno zamówienie, mamy do
czynienia z relacją jeden do wielu pomiędzy tabelami klientów i
zamówień. W podanym powyżej przykładzie klient ALFKI złożył dwa
zamówienia.
Do pobrania powiązanych rekordów z tabeli potomnej lub z tabeli
rodzica można użyć obiektu DataRelation. Na przykład podczas pracy z
rekordem opisującym klienta ANTON możemy pobrać kolekcję rekordów
opisujących zamówienia tego klienta. Podobnie, podczas pracy z
rekordem przedstawiającym zamówienie numer 10507 można użyć obiektu
DataRelation do pobrania rekordu opisującego klienta, który złożył to
zamówienie (jest to klient ANTON).
Ograniczenia
W większości baz danych obiekty DataSet obsługują ograniczenia jako
sposób zagwarantowania integralności danych. Ograniczenia są regułami
stosowanymi podczas dopisywania, modyfikowania i usuwania rekordów z
tabeli. Możliwe jest zdefiniowanie dwóch typów ograniczeń:
*
ograniczenie powtarzalności danych (unique constraint) — sprawdza,
czy nowe wartości, wprowadzane w danej kolumnie, są unikalne w
całej tabeli,
*
ograniczenie klucza obcego (foreign-key constraint) — definiuje
reguły określające sposób aktualizacji rekordów potomnych w
przypadku modyfikacji lub usunięcia rekordu w tabeli-rodzicu.
Ograniczenia zdefiniowane dla danego obiektu DataSet przypisywane są
albo do poszczególnych tabel (ograniczenie klucza obcego), albo do
kolumn (ograniczenie powtarzalności gwarantujące unikalność wartości w
kolumnie). Ograniczenia reprezentowane są przez obiekty typu
UniqueConstraint oraz ForeignKeyConstraint. Przechowywane są w
kolekcji Constraints obiektu DataSet. Ograniczenie powtarzalności dla
danej kolumny można także zdefiniować, ustawiając wartość właściwości
Unique tej kolumny na true.
Obiekt DataSet posiada właściwość typu Boolean o nazwie
EnforceConstraints, pozwalającą włączać i wyłączać sprawdzanie
ograniczeń. Domyślnie wartość tej właściwości ustawiona jest na true.
Czasami jednak potrzebne jest tymczasowe wyłączenie sprawdzania
ograniczeń. Najczęściej sytuacja taka ma miejsce wtedy, gdy zmieniamy
rekord w sposób, który spowoduje naruszenie ograniczeń. Po zakończeniu
edycji — a tym samym po przywróceniu poprawnego stanu tabeli — możemy
ponownie włączyć sprawdzanie ograniczeń.
W Visual Studio ograniczenia tworzone są niejawnie podczas
definiowania obiektu DataSet. Zdefiniowanie klucza podstawowego dla
jakiejś tabeli powoduje niejawne utworzenie ograniczenia
powtarzalności dla kolumny tego klucza podstawowego. Ograniczenie
powtarzalności dla innych kolumn można także zdefiniować, ustawiając
wartość właściwości Unique danej kolumny na true.
Utworzenie obiektu DataRelation powoduje utworzenie ograniczenia
klucza obcego. Obiekt DataRelation — poza pobieraniem informacji o
powiązanych ze sobą rekordach — umożliwia także zdefiniowanie reguł
ograniczenia klucza obcego.
Szersze informacje na temat stosowania obiektów DataRelation jako
ograniczeń klucza obcego można znaleźć w artykule Obiekt DataRelation
— wprowadzenie. Natomiast informacje na temat tworzenia ograniczeń
metodami programistycznymi znajdują się w artykule Określanie
ograniczeń dla tabeli.
Aktualizowanie obiektów DataSet oraz składnic danych
Po wprowadzeniu zmian do rekordów znajdujących się w obiekcie DataSet,
zmiany te muszą zostać zapisane także w bazie danych. Aby zmiany
wprowadzone w obiekcie DataSet wprowadzić do bazy danych, należy
wywołać metodę Update obiektu DataAdapter, pośredniczącego w
komunikacji pomiędzy obiektem DataSet a odpowiednim źródłem danych.
Klasa DataRow, służąca do operowania na pojedynczych rekordach,
zawiera właściwość RowState. Wartość tej właściwości wskazuje, czy od
chwili pierwszego załadowania tabeli z bazy danych dany rekord został
zmodyfikowany, dopisany lub usunięty. Możliwe wartości właściwości
RowState to Deleted, Modified, New oraz Unchanged. Wartość właściwości
RowState pozwala metodzie Update określić, które rekordy muszą zostać
zapisane w bazie danych i jakiego polecenia (dopisanie, modyfikacja,
usunięcie) należy do tego celu użyć.
Aby dowiedzieć się więcej na temat aktualizowania danych, warto
przeczytać artykuł Aktualizowanie obiektów Dataset w Visual Studio
.NET.
Zobacz także (materiały w języku angielskim)
Dostęp do danych z użyciem ADO.NET — wprowadzenie | Obiekt DataAdapter
— wprowadzenie | Tworzenie obiektów DataSet za pomocą narzędzi Visual
Studio | Tworzenie typizowanych obiektów DataSet za pomocą narzędzia
Component Designer | Tworzenie schematów XML i obiektów DataSet |
Dodawanie istniejących typizowanych obiektów DataSet do formularza lub
komponentu | Dodawanie nietypizowanych obiektów DataSet do formularza
lub komponentu | Dane — instrukcje krok po kroku

  • LAS OPOSICIONES CORRESPONDIENTES A LA OFERTA DE EMPLEO PÚBLICO
  • PRESENT CONTINUOUS WORKSHEET 1 PRACTICE IN PAIRS THE
  • UNIVERSITY OF JORDAN FACULTY OF SCIENCE MATHEMATICS DEPARTMENT PHD
  • ISSUED 4595 TRIPLE J FARMS LLAMA PLASMA PRODUCT CODES
  • ASTMA OSKRZELOWA U DZIECI ANNA STODOLAK ASTMA
  • EL MODELO CANVAS EN LA PRÁCTICA 6 ECTS ESCUELA
  • CENTRE EDUCATIU JACINT VERDAGUER PLA D’ACOLLIDA ÍNDEX 1 PRESENTACIÓ
  • A OSNOVNI PODACI O PROJEKTU I ORGANIZACIJI NAZIV I
  • B ID TO HOST – RG GO OFFICIAL EVENT
  • AHRC2271 NATIONS UNIES AHRC2271 ASSEMBLÉE GÉNÉRALE DISTR GÉNÉRALE 6
  • SUBDIRECCIÓN GENERAL DE ESTUDIOS Y DOCTRINA DE LA PNC
  • OFERTA TIP DE FURNIZARE A ENERGIEI ELECTRICE LA CONSUMATORII
  • ISSUE BRIEF NO 1 AUGUST 2004 AFTERSCHOOL AND STUDENTS
  • FORSLAG TIL MASTER OG BACHELOR OPPGAVER LIMNOLOGI OG VANNRESSURSER
  • MANUAL ESCOM 5012 CAPITULO I GENERALIDADES 1 OBJETO
  • 2013 – 2014 EĞİTİM ÖĞRETİM YILI 8 SINIF TÜRKÇE
  • MS DEGREE PLAN MODIFICATION FORM SUBMITTED TO THE TOULOUSE
  • PROGRAMACION ACTIVIDAD PARA LA CONMEMORACIÓN DEL 8 DE MARZO
  • ACMT CM PREAPPLICATION CHECKLIST NOTE IF YOU ARE
  • CONTRACT INDIVIDUAL DE MUNCĂ NR 201 (LOCALITATEA) (DENUMIREA UNITĂŢII
  • GOBIERNO DEBE EXIGIR LIBERTAD DE CHILENA PRESA EN ISRAEL
  • INFORMATIKAG ● KLASSE 10 ZEICHEN (CHARACTER) UND ZEICHENKETTEN (STRINGS)
  • PRAVILNIK O SADRŽINI NAČINU IZRADE NAČINU VRŠENJA STRUČNE KONTROLE
  • COMUNICADO DE PRENSA 16062021 MOBILIZE ACELERA SU DESARROLLO HACIA
  • RIDER TO MULTIFAMILY LOAN AND SECURITY AGREEMENT GOVERNMENTAL PAYOR
  • U NIVERZITA PALACKÉHO V OLOMOUCI FAKULTA TĚLESNÉ KULTURY DOKTORSKÝ
  • USECHE 2 DE MEMORIAS DE LETICIA VALLE LLAMA MI
  • FEDERAZIONE ITALIANA GIUOCO CALCIO DELEGAZIONE PROVINCIALE DI MILANO VIA
  • CÓDIGO DE ÉTICA APROBADO POR LA RCA01802 DEL 30AGO2002
  • 120814 MAYOR FRANK EWERT CALLED THE REGULAR MEETING OF