Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 8

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
Wyszukiwano:
w słowach kluczowych:  database design
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
EN
Design of the database includes the decision about the physical storage. This is often overlooked as 1) this cannot be expressed in standard SQL and in result each Database Systems have their own way to specify the physical storage and 2) the decision is often made implicitly. This is dangerous situation as many of the databases use B+ trees as table implementation which stores the data physically sorted by some ordering attribute. The choice of the ordering attribute largely affects read and write operations. Commonly, IDENTITY/AUTO_INCREMENT constraint are being chosen as ordering attributes, due to their easy usage and monotonic nature. In some cases ordering tables by the attributes whose values are drawn from uniform distribution leads to better performance in terms of Transactions-Per-Second. Such cases includes situation when data does fit entirely in-memory or when we can limit the set of physical pages being accessed. In the end, however, We cannot entirely say that either monotonic or random attributes are superior. Both have their pros and cons. In this article We present (1) short description of the data structures in contemporary Database Systems, (2) the advantages and the disadvantages of the two common types which are used as the clustering attributes: GUID and IDENTITY, (3) performance analysis of write operation which compare both data types using B+ tree as primary storage and (4) evaluate the efficiency of these bulk load operation using heap files and B+ trees.
PL
Projektowanie bazy danych wymaga podjęcia decyzji o fizycznej strukturze przechowującej dane. Często wpływ tej decyzji jest niedoceniany ponieważ 1) standard SQL nie precyzuje tego ograniczenia, przez co każdy dostawca Bazy Danych implementuje je po swojemu 2) wybór struktury jest podejmowany niejawnie. Na ogół domyślnymi strukturami są B+ drzewa które są strukturami posortowanymi. Wybór tej konkretnej implementacji tabeli wpływa zarówno na wydajność operacji odczytu jak i zapisu. Ze względu że częstą praktyką jest stosowanie atrybutów IDENTITY/AUTO_INCREMENT jako kluczy głównych, według tych wartości atrybutów ustalany jest fizyczny porządek tabeli. W pewnych przypadkach warto jednak korzystać z atrybutów o wartościach losowych w celu zwiększania przepustowości Bazy Danych (liczonej jako liczba transakcji na sekundę). Takie przypadki obejmują sytuację gdy dane mieszczą się w pamięci operacyjnej lub gdy możemy ograniczyć zbiór fizycznych stron do których Baza Danych będzie się odwoływać. W ogólnym przypadku ani atrybuty monotoniczne, ani losowe nie są lepsze od swoich konkurentów. W tym artykule (1) opisujemy struktury wykorzystywane we współczesnych Bazach Danych, (2) opisujemy zalety i wady dwóch najczęściej wykorzystywanych typów: GUID oraz IDENTITY, (3) prezentujemy analizę wydajności operacji zapisu porównującą oba typy w tabelach implementowanych jako B+ drzewo, (4) analizujemy wydajność operacji wsadowego ładowania zarówno w plikach sekwencyjnych jak i B+ drzew.
EN
Codd’s relational model describes just one possible world. To better cope with incomplete information, extended database models allow several possible worlds. Vague tables are one such convenient extended model where attributes accept sets of possible values (e.g., the manager is either Jill or Bob). However, conceptual database design in such cases remains an open problem. In particular, there is no canonical definition of functional dependencies (FDs) over possible worlds (e.g., each employee has just one manager). We identify several desirable properties that the semantics of such FDs should meet including Armstrong’s axioms, the independence from irrelevant attributes, seamless satisfaction and implied by strong satisfaction. We show that we can define FDs such that they have all our desirable properties over vague tables. However, we also show that no notion of FD can satisfy all our desirable properties over a more general model (disjunctive tables). Our work formalizes a trade-off between having a general model and having well-behaved FDs.
3
Content available remote Complete Conceptual Schema Algebras
EN
A schema algebra comprises operations on database schemata for a given data model. Such algebras are useful in database design as well as in schema integration. In this article we address the necessary theoretical underpinnings by introducing a novel notion of conceptual schema morphism that captures at the same time the conceptual schema and its semantics by means of the set of valid instances. This leads to a category of schemata that is finitely complete and co-complete. This is the basis for a notion of completeness of schema algebras, if it captures all universal constructions in the category of schemata. We exemplify this notion of completeness for a recently introduced particular schema algebra.
PL
W rozdziale przedstawiono podstawowe pojęcia związane z ontologią i jej wykorzystaniem w projektowaniu baz danych. Zaproponowano metodę oceny zgodności modeli konceptualnych danych w kontekście zbioru ontologii, która pozwala ocenić wierność odwzorowania wycinka rzeczywistości za pomocą modelu konceptualnego danych. Całość została zilustrowana przykładem zastosowania przedstawionej metody.
EN
In this chapter the basic concepts of ontology and its use in the design of databases is presented. A method of conformity assessment of conceptual data models in the context of a set of ontology has been introduced. The method allows to assess the quality of representation of a considered problem domain (a part of reality) by means of a conceptual data model. The whole is illustrated by an example of using the presented method.
PL
W pracy przedstawiono proces modelowania danych na poziomie konceptualnym. Omówiono podstawowe etapy procesu modelowania danych oraz wyjaśniono kluczowe problemy występujące w tym procesie. Ponadto, zaproponowano miary do oceny jakości modeli. Przykład ilustrujący realizację podstawowych etapów procesu modelowania danych jest jednocześnie formą dyskusji problemów związanych transformacją modeli na poziomie konceptualnym, wykorzystując refaktoryzację i uściślanie w celu poprawy jakości modeli.
EN
The paper presents the process of data modeling at conceptual level. There are discussed the basic stages of the data modeling process. Key problems specific for this process are explained. Additionally the measures of quality data model evaluation are defined. Example of development of conceptual data models is shown. The way of improving the quality of the data models by using refactoring and refining is discussed.
6
PL
W artykule omówiono pewien specyficzny sposób reprezentacji danych, który w pewnych sytuacjach może być stosowany w miejsce klasycznego podejścia relacyjnego. Jest on stosunkowo mało znany i choć zakres jego stosowalności jest ograniczony a pewne niekorzystne właściwości znaczne, to warto go poznać, gdyż istnieją obszary, gdzie jego stosowanie może przynieść wymierne korzyści. Mowa tu o tzw. podejściu Entity-Attribute-Value, w skrócie EAV. Jest ono całkowicie różne od podejścia relacyjnego. W pracy pokazano główne założenia EAV wraz z przykładami oraz omówiono jego podstawowe zalety i wady. Krótko omówiono również pewne alternatywne rozwiązanie do EAV, które posiada niektóre cechy EAV, a jednocześnie nie burzy tak bardzo podejścia relacyjnego.
EN
In the paper a specific kind of data representation is presented. In some situations it can be used in place of classical relational approach. This data representation, although not new, is not widely known, and in spite of some serious limitations, can be used in many specific database areas. We describe the Entity-Attribute-Value (EAV) approach. This approach is totally different to the relational one. In the paper we give an overview of the EAV as well as we show the main advantages and disadvantages. Also, we show an alternative approach to EAV which does not suffer the EAV limitations.
PL
Coraz większe wymagania stawiane systemom informatycznym oraz konkurencja rynkowa zmusza producentów oprogramowania nie tylko do podnoszenia jakości tworzonych produktów, ale także do wytwarzania ich w coraz krótszym czasie. Aby sprostać rosnącym wymaganiom niezbędne jest, poza odpowiednią organizacją projektu i właściwym zarządzaniem, stosowanie narzędzi wspomagających proces projektowania - narzędzi CASE (ang. Computer Aided/Assisted Software/System Engneering). Celem tej publikacji jest scharakteryzowanie programów typu CASE, wskazanie obszarów zastosowań narzędzi CASE w projektowaniu relacyjnych baz danych, a także prezentacja przykładowej aplikacji CASE, wykonanej w 2002 roku jako praca dyplomowa inżynierska na Wydziale Informatyki i Zarządzania Politechniki Wrocławskiej.
EN
The work characterizes CASE tools and points to the areas of their application in relational database design. A sample CASE application is presented, supporting the structural method of database design. This application has been implemented as an M.Sc. thesis at the Department of Computer Science of the Wroclaw University of Technology.
EN
The database was created in response to the need of obtaining complex information necessary for efficient management of the Polish coastal zone. Database preparation processes are co-ordinated within the EU PHARE project focusing on harmonising such databases in Estonia, Lithuania, Latvia and Poland. The majority of the information concerns the geographical objects, therefore the database was generated with application of Geographic Information Systems.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.